Spécification de contenu sur Zeste de Savoir, ou sa version brouillon

Bah ya deux cas: Soit le contenu est créé online et c'est notre tambouille invisible pour l' utilisateur qui se fait donc autant que les dev disent ce qui marche le mieux. Soit c'est écrit offline puis importé et je ne vois pas ce qui nous empêche de faire des modif pour la compatibilité.

Ça peut aussi être plus complexe : je crée mon tuto sur ZdS, je l'exporte, je l'édite, je l'importe. Puis je fais (ou un co-auteur fait) des modifs en ligne, puis je réexporte le tuto. Dans l'idéal, je devrais retrouver les mêmes fichiers que lors de mon importation. S'il y a modification de la structure ou du manifest, c'est quand même un peu gênant pour les auteurs.

Concernant le problème slug/nom, je vois les choses comme ça (n'hésitez-pas à me dire si je me plante). Pour chaque extrait (base atomique) :

• On a un nom de fichier ;
• On a un titre d'extrait ;
• On a un slug (pour accéder à l'extrait via l'URL).

Et on a ces contraintes :

1. Le slug doit être unique au sein d'un conteneur parent
2. Le slug doit être rétrocompatible (SEO)
3. Le nom de fichier doit être unique sur le système de fichier (presque évident)

Les relations entre les trois sont faites dans le fichier manifest.json. Dans le cas de l'édition en-ligne, ils sont reliés ainsi :

1
2

slug = slugify(title)
path = slug + ".md"

Ce qui satisfait presque (aux collisions gérées par l'ajout du compteur dans le slug près) les contraintes énoncées. Mais rien n'oblige à utiliser ce schéma. Donc pour moi les trois clefs ont leur place dans le manifest.json, et pourrons être utilisées.

Le problème avec l'introduction et la conclusion, c'est que ce sont des noms de fichiers (et pas des slugs) réservés. C'est donc la contrainte n°3 qui est mise en danger si les auteurs décident d'utiliser leurs propres noms de fichier n'importe comment. Pour moi la solution la plus simple est en effet d'utiliser un nom de fichier légèrement différent, qui permette d'utiliser les slugs introduction et conclusion avec des fichiers nommés introduction.md et conclusion.md.

Dans cette optique la proposition de Introduction.md et Conclusion.md est la plus simple. Pourquoi pas coupler ça à une clef introduction=True dans le fichier JSON, mais c'est plus une question de performance qu'autre chose.

Une fois encore, je me répette et je répette ce qu'artragis a dit "titre != slug". L'auteur est libre de son titre, et est libre de son slug tant qu'il est unique (à l'échelle du conteneur, peut-être). Si un auteur a envie d'appeller toutes ces intro "intro.md" et son extrait introductif "introduction.md", il fait ce qu'il veux

Je vais donc modifier la règle :

Le slug doit être unique au sein du même conteneur. Il doit également être différent de celui du conteneur parent et de celui de l'introduction et de la conclusion (qui, par défaut, sont introduction et conclusion)*.

* ou bien, si on considère que ce sont des noms de fichiers comme "Introduction.md", cette dernière n'as pas lieu d'être.

C'bon comme ça ?

EDIT: j'avais pas vu la réponse de Luthaf, mais j'aime énormément.

J'aime bien sauf le truc sur true / false (et donc pour laisser décider à l'auteur le nom de ses fichiers d'intro / conclu)

Je n'arrive pas à trouver de solution vraiment meilleure que ce qui a été proposé concernant la manière de gérer les slugs, alors je vais me contenter de faire deux remarques.

• Dans le manifest.json, les contenants sont identifiés par object : "container" et les extraits sont identifiés par type : "extract" : c'est incohérent. Vu que cette clé sert uniquement à distinguer si les objets enfants sont des extraits ou des conteneurs, la clé doit être la même dans les deux types, sinon il faut connaître le type pour savoir quelle clé regarder.
• Pierre, tu n'arrêtes pas d'utiliser le mot « assumer » comme s'il avait le sens de l'anglais assume. Ce n'est pas le cas : en français, on dit « présumer ».

Je n'arrive pas à trouver de solution vraiment meilleure que ce qui a été proposé concernant la manière de gérer les slugs, alors je vais me contenter de faire deux remarques.

• Dans le manifest.json, les contenants sont identifiés par object : "container" et les extraits sont identifiés par type : "extract" : c'est incohérent. Vu que cette clé sert uniquement à distinguer si les objets enfants sont des extraits ou des conteneurs, la clé doit être la même dans les deux types, sinon il faut connaître le type pour savoir quelle clé regarder.

Erreur de recopiage de ma part, les deux sont bien object (pour les raisons que tu mentionnes)

good point. J'imagine que taper deux moins de mémoire en anglais m'ont forcé à quelques facilités de langage, j'en fait énormément de ces temps-ci. J'éditerais pour que ça soit moins le cas

Bon, j'ai mis à jour le texte, en tenant compte de vos différentes remarques, n'hésitez pas à me dire si j'en ai oublié.

J'ai aussi rajouté un point sur la mise en production, n'hésitez surtout pas à le lire attentivement (parce qu'il est potentiellement explosif) et à me dire ce que vous en pensez. D'avance merci

Je rappelle également pour ceux qui ne l'auraient pas vu qu'artragis a créé un Redmine pour la ZEP-12, donc tout ce qui est dit ici sera à un moment transposé là-bas. Merci à lui

va faire un stock d'aspirine

J'avoue que les 5 pages de discussion m'ont complètement perdu et que j'ai la flemme de les lire en détail.

Est-ce que je peux me baser sur le premier post uniquement vu qu'il a l'air à jour ?

Salut SpaceFox

J'ai mis à jour mon premier message de manière à montrer ce qui avait été discuté au cours de ces 5 (!) pages, et ce qui mérite pour moi encore discussion, donc pour moi tu peux te baser là dessus (c'est un pavé en soit, ceci dit). Enjoy !

Alors, voici mes réactions à tout ceci. Toutes les citations viennent du premier post.

D'abord, bravo et merci pour l'impressionnant travail effectué.

il a notamment été discuté de l'intérêt ou pas d'avoir un slug qui était unique sur le contenu lui-même ou dans le conteneur parent uniquement. Actuelement, a part des arguments d'ordre estétique, je ne vois pas pourquoi une url du type "http://zestedesavoir.com/tutoriel/un-contenu/un-contenu/un-contenu" serait bloquant en quoique ce soit, puisqu'on sait qui est quoi (mais j'y réfléchi toujours).

Je ne vois aucun problème à avoir une URL du type "http://zestedesavoir.com/tutoriel/un-contenu/un-contenu/un-contenu".

Par contre, ça implique que les fichiers .md correspondants soient dans des dossiers différents, et que l'arborescence soit implicite.

Pourquoi ne pourrait-on pas avoir plusieurs extraits dans un article, qui équivaudrait à un mini-tuto, mais avec un but différent ? Il me semble par contre évident qu'un article ne peut pas contenir des chapitres.

Avoir droit aux extraits multiples dans un article me semble pratique pour tous les articles un peu longs.

Le déplacement d'un conteneur ou d'un extrait reviendrait simplement à donner un nouveau slug à ce dernier, en accord avec ce qui est déjà présent !!

Je ne comprends pas où est le point à discuter ici ?

On distingue actuelement deux types de métadonnées (metadata) : celles qui sont versionnées (et donc reprises dans le manifest.json) et celle qui ne le sont pas. La liste exhaustive de ces dernière (à l'heure actuelle) est la suivante :

Là pour moi on a un problème : toutes les méta-données devraient être versionnées, sauf si évidemment ça n'a pas de sens. Subséquemment :

• Les hash des différentes versions devraient être des branches Git (on a un outil, autant l'utiliser).
• Les auteurs, les catégories, l'URL de la miniature, la source, la présence de JSFiddle devraient être dans le JSFiddle
• La date de création est naturellement connue dans Git
• Les dates de publication et de dernière modification ne sont pas versionnables et donc doivent rester en BDD.

À noter que je parle des informations sources ici : on peut avoir besoin de dénormaliser le modèle et donc d'ajouter une copie de ces informations ailleurs (en BDD par exemple) pour des raisons de performance.

Pour des raisons de facilité, certaines des métadonnées versionnées sont également stockée en base de donnée : le titre, le type de contenu, la licence et la description. En ce qui concerne la version de celle-ci, c'est TOUJOURS celle correspondant à la version brouillon qui sont stockées, il ne faut donc en aucun cas les employer pour résoudre une URL ou à travers une template correspondant à la version publiée.

À mon sens c'est une erreur.

Si on a quatre versions utilisables sur le site (brouillon, bêta, validation et publique) on devrait avoir 4 objets avec ces informations en base.

Talus propose de mettre ce champ à "2.0"

Quel serait l'intérêt d'avoir "2.0" et non "2" ?

Si rien n'est indiqué, ZdS tentera d'présumer le type en fonction de ce que le contexte lui indique.

Cette règle est floue, et je n'aime pas les règles floues. Je propose : "Si rien n'est indiquée, le contenu est géré comme un tutoriel".

Si on a pas de problèmes d'incompatibilités, on peut le rendre obligatoire. Ou au moins définir une règle claire pour deviner le type de contenu en cas d'absence de ce champ.

Si ce champ n'est pas indiqué, ZdS tentera de deviner le type […] Il est préférable de l'indiquer pour éviter les surprises.

Bien qu'ici on ait une règle un peu plus claire, il faudrait la rendre certaine (donc sans "tenter de…" et synonymes dans la formulation). Voire rendre ce champ obligatoire.

[Le passage sur l'intro et la conclusion]

Il existe des cas où le conteneur n'a pas d'intro ou de conclusion (plus fréquent).

Pour moi, on devrait avoir 2 champs introduction et conclusion (facultatifs) qui contiennent des chemins relatifs à la racine du contenu vers un fichier formaté en markdown. Le nom du fichier étant libre, il ne bloque aucun slug.

Les versions alternatives ne me semblent pas vraiment résoudre de problème tout en étant plus compliquées et moins souples (les champs sont toujours présents, obligation d'utiliser des caractères inutilisés ailleurs, moins de souplesse si on veut manipuler le dépôt à la main).

text Ce champ est obligatoire, car il est employé par le système pour déterminer le type d'objet en cas d'absence de celui-ci.

C'est une très mauvaise raison de rendre un champ obligatoire. Un champ peut être obligatoire parce que sans lui le fonctionnement n'a pas de sens, ça OK. Mais pas pour palier un champ mis en facultatif ailleurs.

Cela dit, un extrait sans texte n'a pas de sens, donc ce champ est bel et bien obligatoire.

Ce que je propose est bien que TOUT les contenus (article et tutos) soient stockés au même endroit dans ZDS_APP['content']['repo_path'], qui équivaudrait probablement à /content-private/

et

Ce que je propose est bien que TOUT les contenus publiés (article et tutos) soient stockés au même endroit dans ZDS_APP['content']['repo_public_path'], qui équivaudrait probablement à /content-public/.

Je ne vois pas de problème avec ça.

Attention, la proposition 3 est dangereuse : si on fait cela, ça veut dire que cette partie ne peut pas être modifiée ensuite, sauf si on exporte à nouveau le tutoriel. IL faut donc bien réfléchir au cas ou ça pourrait poser problème avant d'accepter celle-ci

Je ne comprends pas où est le danger, puisqu'on ne modifie jamais le contenu public à la main mais qu'on le valide à chaque fois, ce qui fait rejouer toute la procédure de validation – et donc régénère tous les fichiers concernés.

Dans l'idéal, on ne devrait pas avoir à ce servir de GIT pour afficher la version publiée d'un contenu.

Pas d'accord. On ne doit pas avoir à se servir de Git pour afficher la version publiée d'un contenu. Sans conditionnel. En particulier, ça implique de ne pas avoir d'informations Git (dossiers .git) dans le dossier de contenu public.

le manifest.json est employé pour générer le sommaire

Pour moi, le sommaire doit être généré à la publication, en HTML ; les méta-données utiles à l'affichage présentes en base, et le manifest.json complètement absent du dossier de publication (puisqu'il devient inutile).

additionné de l'éventuelle possibilité de faire suivant/précédent

Qu'est-ce qui nous empêche de générer ces liens précédent / suivant à la validation ?

Pour moi le principal impact de mes 2 dernières remarques, c'est que si on fait une grosse mise à jour du HTML front des contenus, on doit régénérer les HTML. Vu ce qu'on gagne à côté (la consultation se résume à lire des HTML), est-ce vraiment un problème ?

Des coeurs pour toi cher DTC. On va pouvoir faire un truc sympa avec tout ça.

Merci SpaceFox pour ce long (et complet) retour, je vais essayer d'y répondre comme je peux. Je suis globablement d'accord, ceci dit.

D'abord, bravo et merci pour l'impressionnant travail effectué.

Mais de rien, puis c'pas fini, faut que je mette mon nez dans les URLs

il a notamment été discuté de l'intérêt ou pas d'avoir un slug qui était unique sur le contenu lui-même ou dans le conteneur parent uniquement. Actuelement, a part des arguments d'ordre estétique, je ne vois pas pourquoi une url du type "http://zestedesavoir.com/tutoriel/un-contenu/un-contenu/un-contenu" serait bloquant en quoique ce soit, puisqu'on sait qui est quoi (mais j'y réfléchi toujours).

Je ne vois aucun problème à avoir une URL du type "http://zestedesavoir.com/tutoriel/un-contenu/un-contenu/un-contenu".

Par contre, ça implique que les fichiers .md correspondants soient dans des dossiers différents, et que l'arborescence soit implicite.

Tout à fait d'accord.

Pourquoi ne pourrait-on pas avoir plusieurs extraits dans un article, qui équivaudrait à un mini-tuto, mais avec un but différent ? Il me semble par contre évident qu'un article ne peut pas contenir des chapitres.

Avoir droit aux extraits multiples dans un article me semble pratique pour tous les articles un peu longs.

C'est aussi ce que je pense, mais je préfère poser la question

Le déplacement d'un conteneur ou d'un extrait reviendrait simplement à donner un nouveau slug à ce dernier, en accord avec ce qui est déjà présent !!

Je ne comprends pas où est le point à discuter ici ?

Y'en a pas, c'est juste que le point "déplacement d'un truc" semble poser problème à certaines personnes, alors que ça me semble au contraire très simple

On distingue actuelement deux types de métadonnées (metadata) : celles qui sont versionnées (et donc reprises dans le manifest.json) et celle qui ne le sont pas. La liste exhaustive de ces dernière (à l'heure actuelle) est la suivante :

Là pour moi on a un problème : toutes les méta-données devraient être versionnées, sauf si évidemment ça n'a pas de sens. Subséquemment :

• Les hash des différentes versions devraient être des branches Git (on a un outil, autant l'utiliser).
• Les auteurs, les catégories, l'URL de la miniature, la source, la présence de JSFiddle devraient être dans le JSFiddle
• La date de création est naturellement connue dans Git
• Les dates de publication et de dernière modification ne sont pas versionnables et donc doivent rester en BDD.

À noter que je parle des informations sources ici : on peut avoir besoin de dénormaliser le modèle et donc d'ajouter une copie de ces informations ailleurs (en BDD par exemple) pour des raisons de performance.

Je suis tout à fait d'accord avec toi, mais je pense que c'est le domaine de la ZEP-08, en tout cas pour l'histoire des branches (tu te rappelle du débat sur le workflow de ZdS ? Même problème ici). Pour ce qui est des données, je laisse ça aussi à la ZEP-08, parce que c'est un peu tendu : pour prendre un exemple, celui de la miniature, l'url peut très bien changer dans le futur et la miniature ne plus exister. Pas moyen d'empecher ça autrement qu'en interdisant à l'image de disparaitre. Pour la date de création, par contre, c'est peut-être possible de la choper dans git, mais je sais pas à quel prix.

Pour des raisons de facilité, certaines des métadonnées versionnées sont également stockée en base de donnée : le titre, le type de contenu, la licence et la description. En ce qui concerne la version de celle-ci, c'est TOUJOURS celle correspondant à la version brouillon qui sont stockées, il ne faut donc en aucun cas les employer pour résoudre une URL ou à travers une template correspondant à la version publiée.

À mon sens c'est une erreur.

Si on a quatre versions utilisables sur le site (brouillon, bêta, validation et publique) on devrait avoir 4 objets avec ces informations en base.

Proposition intéréssante. Couteuse en terme de stockage en BDD, mais intéréssante. Faut que je réfléchisse ceci dit si c'est appliquable en pratique (parce qu'il y a deux solution : répliquer tout les champs qui le nécéssite, genre title deviendrait draft_title, beta_title, validation_title, public_title ou créer plusieurs objets avec un "type" qui indiquerait de quel version il s'agit). Ou alors, on cherche à réduire encore cette empreinte en base de donnée et on vire la duplication (seul le slug doit y rester)

Talus propose de mettre ce champ à "2.0"

Quel serait l'intérêt d'avoir "2.0" et non "2" ?

Plus de granularité, I guess. Il a invoqué SEMVER et le fait qu'il fallait se reposer sur l'ancienne implémentation pour afficher les anciennes versions.

Si rien n'est indiqué, ZdS tentera d'présumer le type en fonction de ce que le contexte lui indique.

Cette règle est floue, et je n'aime pas les règles floues. Je propose : "Si rien n'est indiquée, le contenu est géré comme un tutoriel".

Si on a pas de problèmes d'incompatibilités, on peut le rendre obligatoire. Ou au moins définir une règle claire pour deviner le type de contenu en cas d'absence de ce champ.

Accordé. Ça vient du fait que j'ai pas l'habitude de faire ça et que je suis pas sur de ce que je fait, mes conditionnels.

Si ce champ n'est pas indiqué, ZdS tentera de deviner le type […] Il est préférable de l'indiquer pour éviter les surprises.

Bien qu'ici on ait une règle un peu plus claire, il faudrait la rendre certaine (donc sans "tenter de…" et synonymes dans la formulation). Voire rendre ce champ obligatoire.

Rendre ce champ obligatoire n'est pas un problème.

[Le passage sur l'intro et la conclusion]

Il existe des cas où le conteneur n'a pas d'intro ou de conclusion (plus fréquent).

Pour moi, on devrait avoir 2 champs introduction et conclusion (facultatifs) qui contiennent des chemins relatifs à la racine du contenu vers un fichier formaté en markdown. Le nom du fichier étant libre, il ne bloque aucun slug.

Les versions alternatives ne me semblent pas vraiment résoudre de problème tout en étant plus compliquées et moins souples (les champs sont toujours présents, obligation d'utiliser des caractères inutilisés ailleurs, moins de souplesse si on veut manipuler le dépôt à la main).

Long débat, mais je vois un peu ce qui bloque, en fait (j'ai eu le déclic tantôt). En fait, les slugs ne sont pas bloqué de facto par la spécification, mais par l'implémentation que je compte en faire. Donc en fait, tout ce débat n'as pas lieu d'exister

text Ce champ est obligatoire, car il est employé par le système pour déterminer le type d'objet en cas d'absence de celui-ci.

C'est une très mauvaise raison de rendre un champ obligatoire. Un champ peut être obligatoire parce que sans lui le fonctionnement n'a pas de sens, ça OK. Mais pas pour palier un champ mis en facultatif ailleurs.

Cela dit, un extrait sans texte n'a pas de sens, donc ce champ est bel et bien obligatoire.

Absolument d'accord.

Ce que je propose est bien que TOUT les contenus (article et tutos) soient stockés au même endroit dans ZDS_APP['content']['repo_path'], qui équivaudrait probablement à /content-private/

et

Ce que je propose est bien que TOUT les contenus publiés (article et tutos) soient stockés au même endroit dans ZDS_APP['content']['repo_public_path'], qui équivaudrait probablement à /content-public/.

Je ne vois pas de problème avec ça.

Cool

Dans l'idéal, on ne devrait pas avoir à ce servir de GIT pour afficher la version publiée d'un contenu.

Pas d'accord. On ne doit pas avoir à se servir de Git pour afficher la version publiée d'un contenu. Sans conditionnel. En particulier, ça implique de ne pas avoir d'informations Git (dossiers .git) dans le dossier de contenu public.

Je n'en étais pas encore sur à l'époque, maintenant j'ai une petite idée de comment faire, donc je confirmer le "doit".

le manifest.json est employé pour générer le sommaire

Pour moi, le sommaire doit être généré à la publication, en HTML ; les méta-données utiles à l'affichage présentes en base, et le manifest.json complètement absent du dossier de publication (puisqu'il devient inutile).

C'est ce qui devrait ce passer dans l'idéal, et que j'aimerai bien qu'il se passe. J'ai l'impression que ce n'est pas possible, ceci dit, puisque Conteneur et Extraits sont pas en base et que du coup, on va bloquer à un endroit. À priori, donc, j'ai rien contre ce que tu dis, et je vais essayer comme ça (parce que c'est également ce qu'atragis souhaite). Si ça bloque à un endroit, je reviendrait en arrière.

Ta dernière phrase résume bien le débat: il faut faire la balance entre ce qu'on gagne et la souplesse qu'on perd. Pour moi, ça devrait pas être un problème, mais je me devais de soulever la question pour être sur que ça soit clair dans la tête de tout le monde.

Mais de rien, puis c'pas fini, faut que je mette mon nez dans les URLs

Je propose ceci :

• URL des tuto tutoriel/slug-du-tuto tutoriel/slug-du-tuto/slug-conteneur-lvl1 tutoriel/slug-du-tuto/slug-conteneurèlvl1/slug-conteneur-lvl2 Sachant qu'on peut mettre un ancre vers le titre avec #slug-du-titre
• URL des articles article/slug-de-article article/slug-de-article/conteneur-lvl1 pas de conteneur de niveau 2 a priori pour les articles, c'est pas le but du module (Il faudrait donc une version pour les articles du paramètre max-tree-depth)

Pour l'un comme pour l'autre, ajouter le mot "off" ou "beta" entre tuto/article et le slug pour envoyer vers les versions idoines et ce sans problème de changement de lien à chaque version (notamment pour la béta !)

Les slugs étant rendus uniques (peu importe que ça soit au niveau global, du contenu ou du conteneur), pas de problème en vue !

Pour les éditions, on insère les mots "éditer", "supprimer" et "déplacer" au même endroit à la place de "off/beta" (parce qu'on ne peut éditer qu'un tuto en off). Attention néanmoins comme on n'a plus de pk pour les conteneurs et les extraits, pour aller les retrouver va falloir faire de la résolution de fichier.

Ensuite il y a encore les historiques, il me semble mais on peut garder la même idée.

Ta dernière phrase résume bien le débat: il faut faire la balance entre ce qu'on gagne et la souplesse qu'on perd. Pour moi, ça devrait pas être un problème, mais je me devais de soulever la question pour être sur que ça soit clair dans la tête de tout le monde.

En fait, je pense qu'il est tout à fait possible de gérer des fichiers html plus complets mais en gardant un max de modularité en générant la navigation (précédant/suivant, fil d'ariane…) de manière dynamique, ça, ça ne demande pas forcément d'IO. Par contre aller chercher les fichiers un par un comme on le fait aujourd'hui tout en surchargeant l'arbre sous-jacent avec des dossiers .git ça peut clairement en demander.

Ah, j'avais pas vu ta réponse sur redmine, artragis (faut dire que j'ai pas regardé grand chose ces derniers jours, exams oblige). Je suis d'accord avec toi, mais je pensais aussi y aller plus franchement, à savoir faire un bô tableau qui reprendrais la méthode (GET/POST), l'url, les paramètres éventuels et aussi et surtout le name de Django qu'on va être obligé de spécifier maintenant qu'on utilise des MachinChose.as_view() et plus des truc du type zds.tutorial.views.machin_chose. Prémacher le truc et en profiter pour donner au tout une cohérence

Ouais, je sais, je suis fou.

En fait, je pense qu'il est tout à fait possible de gérer des fichiers html plus complets mais en gardant un max de modularité en générant la navigation (précédant/suivant, fil d'ariane…) de manière dynamique, ça, ça ne demande pas forcément d'IO. Par contre aller chercher les fichiers un par un comme on le fait aujourd'hui tout en surchargeant l'arbre sous-jacent avec des dossiers .git ça peut clairement en demander.

L'idée est là, faut la tester. manifest.json ou pas, à ce stade-ci, j'en sais rien, mais plus de git, ça, j'en suis certain.

Je te fais une proposition demain avec toutes les URLS tu as déjà fait beaucoup, ça sert à rien de te surcharger, surtout si tu as des exams.

Je reviens juste sur ce point :

Proposition intéréssante. Couteuse en terme de stockage en BDD, mais intéréssante.

Pas tant que ça en fait, parce qu'on ne stocke pas grand-chose et qu'on a finalement peu de tutos.

Petit calcul :

Quantité de données par tuto

• Titre : 80 octets
• Type de contenu : Disons 8 octets si on met le nom complet
• Licence : 20 octets pour le code
• Description : 200 octets

Soyons fous, on dénormalise tout et on ajoute :

• Hash : 40 octets (20 octets binaires mais stocké sous forme d'un texte hexadécimal –> on double) (d'ailleurs aujourd'hui les champs hash en base sont mal typés)
• Auteurs : 4 octets (FK) x nombre d'auteurs = 12 octets max pour un cas courant
• Catégories : 4 octets (FK) x nombre de catégories = 20 octets max pour un cas courant
• URL de la miniature : 250 octets si on stocke une URL
• URL source : 250 octets
• JSfiddle activé ? : 1 octet
• Date de création : 8 octets (datetime)
• Date de publication : 8 octets (datetime)
• Date de dernière modification : 8 octets (datetime)

Soit un total d'environ 1800 octets de données. Si on y colle plein d'index, on peut facilement monter à 3000 sur le disque.

x 4 par tuto parce qu'il y a max 4 entrées pour un tuto publié (rédaction, beta, validation, publiée).

Combien de tutos a-t-on ?

On a un ratio à peu près fixe dans le temps d'environ 4 tutos non publiés pour 1 tuto publié.

En admettant qu'on arrive un jour à 1000 tutos publiés, on en aura environ aussi 4000 tutos non publiés.

Donc un maxium de 3000 octets x 4 entrés x 1000 tutos publiés + 3000 octets x 3 entrées (un tuto non publié n'a pas d'entrée de publication) x 4000 tutos non publiés = 12 000 000 + 36 000 000 = 48 Mo de données et d'index environ, dans le pire des cas.

Sachant que notre base occupe aujourd'hui environ 200 Mo d'espace disque (fichiers MySQL, donc index compris).

Les URLS dans le module de tutoriel:

Nice, j'aime beaucoup

Par contre, je vois déjà venir le DTC qui te dira que les URLs sont en français.

EDIT: au fait, d'un point de vue conceptuel, ça va nous obliger à interdire le slug beta et off pour les tutoriels.

(et par ailleurs, faut que je réfléchisse au cas ou le slug du tuto change en cours de vie de celui-ci, parce qu'on pourra pas faire de requête sur le slug. Ça va peut-être poser problème, va peut être falloir remettre le pk du contenu dans l'URL :/ )

EDIT: au fait, d'un point de vue conceptuel, ça va nous obliger à interdire le slug beta et off pour les tutoriels.

En effet. Mais est-ce vraiment souhaité d'avoir un tuto qui s'appelle "beta" ou "off"?

La Pk du contenu, ça me gène pas. et ça règle le problème du dessus.

J'ai mis à jour les URL pour que ça soit les pk qui discriminent les contenu.

Bon. Bon bon bon.

Puisque personne n'as plus rien dit, j'en déduit que personne n'as plus rien à dire, donc on va avancer avec ça.

Et j'ai enfin fini mes examens. Du coup, j'ai plein de temps pour coder.

Miam.

Pour ma part, encore une semaine où je ne pourrai pas faire grand chose si ce n'est peut être un peu de QA sur les parties "release v1.5".