Bon, je suis donc repassé sur la base de données.
![[Image: 20i39f.png]](http://i41.tinypic.com/20i39f.png)
J'ai laissé tomber les notes des aventures pour l'instant. Il reste encore probablement des trucs à améliorer, j'attends donc vos commentaires.
Vu sa complexité grandissante, et le nombre de paramètres qu'elle gère, je suis vraiment content d'avoir pris le temps d'en parler sur le forum. Et aussi que le framework puisser générer automatiquement un maximum de fichiers php à partir de cela.
Quelques remarques en vrac :
Sur les clés des avh et des séries
Pour des raisons d'optimisation des moteurs de recherche, et aussi parce que c'est plus joli à l'œil, avoir des noms explicites, c'est bien. Pour cela, chaque aventure doit disposer d'une clé unique créée à partir de son titre. Par exemple, l'aventure Le Retour Des Xhâ Niâs : Le Portail de Tous les Temps, pourrait être à l'adresse http://www.xhoromag.com/avh/le-retour-de...temps.html (le .html est purement bidon par la magie de la ré-écriture d'url, c'est une page avec plein de php dedans) et sa série à http://www.xhoromag.com/collection/le-re...-nias.html. Je suis à peu près sûr que ce genre de clé est très utile, moins sur la forme exacte des url à appliquer. Si un(e) spécialiste en SEO pouvait éclairer ma lanterne...
Sur l'emplacement des images sur le disque
Soit un répertoire public/ à la racine du serveur. Les fichiers relatifs à une avh seraient alors dans public/avh/:id/ où ":id" est l'identifiant en base de l'aventure. Plus exactement, les couvertures, au pluriel car la même image serait en deux tailles différentes, l'une pour sa page dédiée et une autre réduite pour sa présentation courte, seraient dans le sous-dossier cover/, sous les appelations ":key.jpeg" et ":key_s.jpeg", où :key est la clé de l'aventure. Là encore, je ne cracherais pas sur des conseils, parce que cela me semble moyennement propre.
Sur l'emplacement des aventures sur le disque
Les deux formats d'aventure primordiaux sont le PDF et le HTML. Le premier s'explique de lui-même. Pour le deuxième, je pense que l'idéal pour opérer la migration des aventures déjà en ligne est de réaliser un petit script qui fusionne tous les fichiers HTML distincts d'une aventure en un seul gros bloc, avec éventuellement du javascript, que l'on peut stocker quelque part (un peu comme ici). C'est moins compliqué que cela en a l'air, vu que cela n'utilise que des propriétés très simples (ancre html #, style css display).
S'il n'y avait que ceux-là, on pourrait se contenter de les enregistrer à la racine du dossier de l'aventure, sous :key.pdf et :key.html. Mais même en partant du principe que l'on envoie se faire voir les .doc et autres .odt (effectuer la conversion en pdf demandant juste à l'auteur de cliquer sur un gros bouton), il faut aussi un format d'archivage (.zip par exemple) contenant plusieurs fichiers (comme pour 1930). Le truc, c'est qu'une archive peut contenir tout et n'importe quoi... Et quid des fichiers connexes, comme le bêtisier du marais 2 ? Je dois encore réfléchir à la question...
Sur les paramètres descriptifs des aventures
J'ai repris l'idée de Dayne de mettre tous les paramètres descriptifs de l'aventure dans une seule table tags, et de se servir ensuite des catégories de tags pour les trier. Cela limite considérablement les jonctions de tables nécessaires à l'extraction de ces informations. Ensuite, je conviens qu'il faudrait probablement renommer cette table, le mot tags n'étant plus assez générique, et évoquant un rendu graphique finalement indépendant de l'enregistrement. avh_parameters peut-être ?
Sur la place des statuts
Je m'interroge sur l'intérêt de réserver deux tables dans la base de données pour les statuts des membres (admin, modo, expérimenté, nouveau) et des avh (en cours, terminé, en cours de correction, abandonné), au profit de l'utilisation de constantes directement dans le php. Cela limiterait les jonctions de table, et simplifierait à l'extrême certaines fonctions :
J'ai laissé tomber les notes des aventures pour l'instant. Il reste encore probablement des trucs à améliorer, j'attends donc vos commentaires.
Vu sa complexité grandissante, et le nombre de paramètres qu'elle gère, je suis vraiment content d'avoir pris le temps d'en parler sur le forum. Et aussi que le framework puisser générer automatiquement un maximum de fichiers php à partir de cela.
Quelques remarques en vrac :
Sur les clés des avh et des séries
Pour des raisons d'optimisation des moteurs de recherche, et aussi parce que c'est plus joli à l'œil, avoir des noms explicites, c'est bien. Pour cela, chaque aventure doit disposer d'une clé unique créée à partir de son titre. Par exemple, l'aventure Le Retour Des Xhâ Niâs : Le Portail de Tous les Temps, pourrait être à l'adresse http://www.xhoromag.com/avh/le-retour-de...temps.html (le .html est purement bidon par la magie de la ré-écriture d'url, c'est une page avec plein de php dedans) et sa série à http://www.xhoromag.com/collection/le-re...-nias.html. Je suis à peu près sûr que ce genre de clé est très utile, moins sur la forme exacte des url à appliquer. Si un(e) spécialiste en SEO pouvait éclairer ma lanterne...
Sur l'emplacement des images sur le disque
Soit un répertoire public/ à la racine du serveur. Les fichiers relatifs à une avh seraient alors dans public/avh/:id/ où ":id" est l'identifiant en base de l'aventure. Plus exactement, les couvertures, au pluriel car la même image serait en deux tailles différentes, l'une pour sa page dédiée et une autre réduite pour sa présentation courte, seraient dans le sous-dossier cover/, sous les appelations ":key.jpeg" et ":key_s.jpeg", où :key est la clé de l'aventure. Là encore, je ne cracherais pas sur des conseils, parce que cela me semble moyennement propre.
Sur l'emplacement des aventures sur le disque
Les deux formats d'aventure primordiaux sont le PDF et le HTML. Le premier s'explique de lui-même. Pour le deuxième, je pense que l'idéal pour opérer la migration des aventures déjà en ligne est de réaliser un petit script qui fusionne tous les fichiers HTML distincts d'une aventure en un seul gros bloc, avec éventuellement du javascript, que l'on peut stocker quelque part (un peu comme ici). C'est moins compliqué que cela en a l'air, vu que cela n'utilise que des propriétés très simples (ancre html #, style css display).
S'il n'y avait que ceux-là, on pourrait se contenter de les enregistrer à la racine du dossier de l'aventure, sous :key.pdf et :key.html. Mais même en partant du principe que l'on envoie se faire voir les .doc et autres .odt (effectuer la conversion en pdf demandant juste à l'auteur de cliquer sur un gros bouton), il faut aussi un format d'archivage (.zip par exemple) contenant plusieurs fichiers (comme pour 1930). Le truc, c'est qu'une archive peut contenir tout et n'importe quoi... Et quid des fichiers connexes, comme le bêtisier du marais 2 ? Je dois encore réfléchir à la question...
Sur les paramètres descriptifs des aventures
J'ai repris l'idée de Dayne de mettre tous les paramètres descriptifs de l'aventure dans une seule table tags, et de se servir ensuite des catégories de tags pour les trier. Cela limite considérablement les jonctions de tables nécessaires à l'extraction de ces informations. Ensuite, je conviens qu'il faudrait probablement renommer cette table, le mot tags n'étant plus assez générique, et évoquant un rendu graphique finalement indépendant de l'enregistrement. avh_parameters peut-être ?
Sur la place des statuts
Je m'interroge sur l'intérêt de réserver deux tables dans la base de données pour les statuts des membres (admin, modo, expérimenté, nouveau) et des avh (en cours, terminé, en cours de correction, abandonné), au profit de l'utilisation de constantes directement dans le php. Cela limiterait les jonctions de table, et simplifierait à l'extrême certaines fonctions :
Code :
public function isAdmin() {
return ($this->getStatusId() === MemberStatus::ADMIN);
}