Personnellement, je préfère appeler un chat un chat. Le problème du text est que ce n'est juste pas le qualificatif exact… Si on change la structure du manifest à l'aide des documents / etc, autant en profiter pour changer les clés.
Ah, oui, je sais, mais j'ai personnellement pas d'argument en faveur de l'un ou l'autre.
Looping : comme l'indique pierre_24, ce n'est pas la bonne zep pour en discuter. Et le problème étant aussi que comme tout est versionné avec git, dans son propre dépot, il est un peu difficile d'envisager une validation partielle… A moins qu'on puisse en décider autrement lors de la transformation du markdown en html.
En fait je ne parlais pas de validation partielle, mais de pouvoir transférer un extrait ou conteneur d'un tuto à un autre (et vu qu'ici on parle de transfert d'extrait d'un conteneur à un autre…). Je vais prendre un exemple pour être plus clair:
J'écris un tuto A avec deux parties: I) la mécanique du point, II) la mécanique du solide.
Deux scénarios:
Finalement je décide d'en faire deux tutos parce que c'est trop gros. Je crée donc un tuto B, dans lequel je veux importer la partie II du tuto A. Et ensuite j'efface la partie II
J'ai fini d'écrire la partie I), je considére qu'elle est assez complète et indépendante pour être validée et publiée. Pareil, je crée un deuxième tuto, et j'y importe ma partie II, et je la supprime du tuto A. La tuto A est publié, je continue à travailler sur mon tuto B.
Ensuite, je décide de refusionner les deux tutos, je crée donc une partie II dans mon tuto A, et j'y importe le tuto B.
C'est un comportement qui existait sur le SDZV3: détacher un mini-tuto d'un big-tuto, ou importer un mini-tuto dans un big.
J'imagine que si ça existait, c'est que ça répondait à un besoin quelque part. Ça peut être réfléchi aussi, puisque comme tu le dit, ça s'apparente vite fait à du déplacement de conteneur. Après, y'a toute la problématique de la profondeur et des images à traiter, ainsi que d'éventuels cas de rajout de tags ou d'auteurs. Rien est impossible, mais il faut bien le faire
ceci dit, je pense garder ça dans un coin de ma tête pour plus tard, sauf si ça intéresse du monde, parce qu'il y a déjà pas mal à faire avant. Limite, une issue sur github avec un milestone pour pas l'oublier.
Looping : comme l'indique pierre_24, ce n'est pas la bonne zep pour en discuter. Et le problème étant aussi que comme tout est versionné avec git, dans son propre dépot, il est un peu difficile d'envisager une validation partielle… A moins qu'on puisse en décider autrement lors de la transformation du markdown en html.
En fait je ne parlais pas de validation partielle, mais de pouvoir transférer un extrait ou conteneur d'un tuto à un autre (et vu qu'ici on parle de transfert d'extrait d'un conteneur à un autre…). Je vais prendre un exemple pour être plus clair:
J'écris un tuto A avec deux parties: I) la mécanique du point, II) la mécanique du solide.
Deux scénarios:
Finalement je décide d'en faire deux tutos parce que c'est trop gros. Je crée donc un tuto B, dans lequel je veux importer la partie II du tuto A. Et ensuite j'efface la partie II
J'ai fini d'écrire la partie I), je considére qu'elle est assez complète et indépendante pour être validée et publiée. Pareil, je crée un deuxième tuto, et j'y importe ma partie II, et je la supprime du tuto A. La tuto A est publié, je continue à travailler sur mon tuto B.
Ensuite, je décide de refusionner les deux tutos, je crée donc une partie II dans mon tuto A, et j'y importe le tuto B.
C'est un comportement qui existait sur le SDZV3: détacher un mini-tuto d'un big-tuto, ou importer un mini-tuto dans un big.
Oui, c'est bien de ça que je parlais, en le regroupant avec la validation partielle, qui peut elle avoir une solution. Le problème ici, c'est que l'élément (conteneur / extrait donc) n'est pas en BDD. Du coup il n'est pas simple de l'extraire (quid des dépendances, type images par exemple ?) et le réimplémenter dans un autre tuto, qui lui se situe dans un autre dépot en fait. Ce serait du transfert entre dépot en fait ce que tu proposes ici. Ce qui n'est en effet pas le scope de cette ZEP (plutôt celle de la n°8 je dirai à priori).
Bon, j'ai fait une MàJ du truc avec ce qui avait été discuté. On avance
Voici pour moi les points qui demandent encore réflexion :
S'accorder sur le statut clair d'une intro/conclusion. Au début de la discution, il était clairement dit que ce serait des Extrait à part entière, puis au moment de la discution sur la structure JSON, il y a eu une hésitation, que je n'ai pas pu lever en relisant les posts.
S'accorder sur le nom exact des clés, pour que ça devienne un standard une bonne fois pour toute. Comme je l'ai dit, j'ai pas d'avis.
S'accorder sur les métadonnées associées à un tutoriel, ici ou sur la ZEP-08, mais on le dit une bonne fois pour toute, puis on le fait. Parce qu'en gros, de l'autre coté, la réponse était "on versionne tout, point". Oui, mais tout quoi ? Avec quelles clés JSON ? Sur le Conteneur principal ou dans un objet à part ?
Éventuellement s'accorder sur les noms, bien qu'il semble y avoir consensus : Document > Conteneur > Extrait. Mais au moins, c'est sur.
Relire le machin et vérifier que tout le monde est bien d'accord et qu'il y a pas d'autres trucs à discuter (il y en a surement).
comme on est dans l' édition de contenu textuel, je préfère qu'on prenne le jargon habituel pour ne pas dérouter les gens.
a mon sens meta donné ==> stockage dans le manifest.json.
pour être BC avec le site actuel, il n'y a rien à mettre en fait. Même si un consensus a demandé à ce que soit mis le thumbnail.
par contre comme ce sont des meta data , il doit être impératif de presupposer qu'elles peuvent ne pas être incluse de base (par exemple pour un import) ou que des meta non utilisées par zds soient ajoutées.
Conteneur ==> section.
comme on est dans l' édition de contenu textuel, je préfère qu'on prenne le jargon habituel pour ne pas dérouter les gens.
Pourquoi pas
a mon sens meta donné ==> stockage dans le manifest.json.
pour être BC avec le site actuel, il n'y a rien à mettre en fait. Même si un consensus a demandé à ce que soit mis le thumbnail.
Et je suis d'accord avec ce consensus, donc il va falloir ajouter à tout ça un dossier pix, assets ou un truc du genre.
par contre comme ce sont des meta data , il doit être impératif de presupposer qu'elles peuvent ne pas être incluse de base (par exemple pour un import) ou que des meta non utilisées par zds soient ajoutées.
Ça, c'est a l'importation. Y'a actuellement pas de mécanisme d'importation, bien que firm1 aie écrit une PR en ce sens. À fortiori, rien n'interdit l'ajout de métadata externes … Par contre, une partie du code est écrite de manière à vérifier que le manifest.json possède déjà des informations que l'auteur n'as pas forcément (genre les pk). Du coup, je vais aller faire la remarque à Firm1
Oui, il faut bannir les "pk" justement, vu qu'a termes, la bdd n'aura pas connaissance du contenu du manifest. Tout comme les dossiers assets, pix ou autre… Ce sera valable que pour l'éditeur du site. Quand on aura accès au dépot git (pour les plus avancés, cf la zep 8), le type organise ca comme il veut.
la pk avait été mise au départ pour éviter les collisions. Je pense que ces dernières doivent être gérées par la logique du programme : on ne crée pas un extrait "introduction" si une intro existe déjà.
En fait le plus embêtant c'est que du coup il y a sur le site des tutos qui ont cette pk. Soit on la laisse et on se dit juste que c'est le nom du fichier et basta. Soit on doit faire passer un automate qui la supprimera tout en appliquant une opération de gestion des conflits.
Je tiens quand même a attirer l'attention sur l'utilité actuelle des pk. Elle permettent de rendre unique chaque section et extrait.
C'est grâce à elles qu'on peut avoir deux extraits du même noms dans une seule sections. Étant donné qu'on devrait pouvoir déplacer un extrait dans n'importe quelle section, l'identifiant d'un extrait ne doit pas avoir une unicité locale à une section, mais globale à toutes les sections existantes.
Bannir les pk signifie donc qu'il va falloir coder un système qui gère des identifiants automatiques (pour des extraits) de manière transactionnelle et thread safe. En somme, recorder les proprietés ACID d'un SGBD.
Attention, je ne dis pas qu'il ne faut faut pas le faire, mais c'est juste pour attirer l'attention sur les impacts de certains choix et la charge de travail que ça va demander. Par ailleurs, il serait bien aussi que la ZEP décrive les actions suivantes :
La méthode de migration des tutoriels existants (et leurs historique)
Mécanisme de redirection des urls qui ne seront certainement plus les mêmes (à cause des pk qui ne seront plus gérés)
Je pense que le pk dans le nom du fichier/dossier peut être conservé : peu importe comment il s'appelle, après tout, tant qu'il est unique. Mais j'avoue qu'il faudra réfléchir à un mécanisme de gestion des conflits coté serveur pour gérer ces cas limite de fichiers qui ont le même nom (parce que rien ne m'empêche d’appeler un extrait "conclusion"). Du coup, je rejoint l'avis de Firm1 concernant les pk … Comme on n'as plus ça, il va falloir ruser d'une manière ou d'une autre.
La méthode de migration des tutoriels existants (et leurs historique)
Je garde ça en tête, mais la structure est pas encore stabilisée
Mécanisme de redirection des urls qui ne seront certainement plus les mêmes (à cause des pk qui ne seront plus gérés)
Ça, par contre, ça va être un problème réel. Et de manière générale, il va falloir en passer par des comparaisons de type string qui vont être un peu moins drôles à réaliser quand on devra "résoudre" une url. En version online, il faudrait presque reproduire une structure de type B-Tree avec des comparaisons ultra-speed et pas perdre trop en performance.
Pour répondre à Talus, j'ai rien contre le fait de laisser l'utilisateur gérer ces fichiers comme il le souhaite. Le problème, c'est ce qu'il arrive quand il repasse par l'interface web, qui va pas chercher à comprendre ou il a voulu en venir et qui va joyeusement exploser la structure du machin si il tente de rajouter quelque chose.
Ben non, il continuera son bonhomme de chemin dans son coin en fait. Rien n'empêche la cohabitation d'un truc "manuel" et d'un truc automatique… Lors de l'upload de ressources (des images, …), il va se les faire tout seul comme un grand dans un dossier assets, pix ou autre. Les fichiers md auront juste un lien vers ceux-ci, c'est tout.
Les assets ne doivent pas être présent dans le manifest hein. Elles sont juste là dans le dépot, et c'est tout…
Le problème des pk c'est que l'utilisateur ne peut pas savoir où ca en est (et d'ialleurs, ne doit pas le savoir). Comme un fichier du même nom en écrase un, là c'est pareil… OK pour que l'interface web ajoute genre un hash aléatoire dans le nom du fichier, mais c'est tout en fait, y'a pas de persistance ni rien à mettre là dedans.
Rien qu'avec un hash de 7 caractères, comprenant chiffres & lettres, et même sans casse, tu as a peu près une chance sur 36^7 d'avoir le même hash, donc "ca va"… Et le fait que ce soit un caractère aléatoire montre bien que c'est juste l'éditeur qui fait ca pour se détromper. Libre à l'utilisateur d'en inclure ou non. Lors de l'édition, on édite le fichier… et c'est tout !
@Talus : je suis absolument d'accord avec ce que tu dis, j'ai juste mal exprimé ce qui pour moi était le problème. Dans la version actuelle, un conteneur=un dossier. J'imagine que quand on va appliquer cette ZEP (et la 12), on va conserver cette manière logique de travailler. Ceci dit, imaginons qu'un auteur trouve plus logique de faire un dossier par partie et dans celui ci, faire des fichier genre 1_chapitre1_1_introducion.md, 1_chapitre1_2_pourquoi-le-html-5.md et ainsi de suite (en gros, pas de dossier par chapitre). Cette organisation se vaut tout autant, et à fortiori, rien ne l'empêche. Là ou je pense qu'il y a un problème, c'est au moment ou l'auteur va rajouter, via l'interface web, un nouvel extrait dans son chapitre… Qui ne respectera pas sa convention et va foutre en l'air son organisation. Ce qui n'est pas un vrai problème, tout va continuer à fonctionner, mais voilà.
Rien qu'avec un hash de 7 caractères, comprenant chiffres & lettres, et même sans casse, tu as a peu près une chance sur 36^7 d'avoir le même hash, donc "ca va"… Et le fait que ce soit un caractère aléatoire montre bien que c'est juste l'éditeur qui fait ca pour se détromper. Libre à l'utilisateur d'en inclure ou non. Lors de l'édition, on édite le fichier… et c'est tout !
S'accorder sur le statut clair d'une intro/conclusion
ce sont des extraits comme les autres. Faut juste mettre une logique applicative qui autorise un extrait introductif et un extrait de conclusion lorsqu'un conteneur contient d'autres conteneurs.
Après on peu aussi garder comme maintenant, mais ça ajoute de la gestion de modèle supplémentaire je trouve.
Pourquoi pas. Hash sur le timestamp de création (+ pk de l'user, pour les collisons inter-auteurs) ? Sur autre chose ?
S'accorder sur le statut clair d'une intro/conclusion
ce sont des extraits comme les autres. Faut juste mettre une logique applicative qui autorise un extrait introductif et un extrait de conclusion lorsqu'un conteneur contient d'autres conteneurs.
Après on peu aussi garder comme maintenant, mais ça ajoute de la gestion de modèle supplémentaire je trouve.
C'est bien ce que Alex-D et toi on exprimé à plusieurs reprises et que j'avais compris. Le problème, c'est que ce qu'a proposé Alex-D par la suite au niveau de la structure reviens exactement au même que de considérer les extraits comme des machins à part, puisqu'on leur donne un statut spécial dans les conteneurs avec les clés introduction et conclusion (y compris, et c'est là toute la subtilité, dans les Conteneur1 d'Extrait). C'est pour ça que je pose la question.
en fait perso je ne vois pas pourquoi on veut absolument s'entêter avec le hash.
Très sérieusement, je vois trois cas d'utilisations :
je crée le tuto en externe, puis je l'importe sur zds :
aucun doublon n'est possible car de base le mec te donnera une liste de fichiers et comme les fichiers sont nécessairement différents les uns des autres, les doublons sont impossibles.
je crée un tuto en interne l'exporte pour l'éditer hors ligne (voir utilise git comme veut le définir la ZEP 8) puis le réimporter (zds editeur créé par firm1)
seul risque de doublon : nommage de deux chapitres de la même manière lors de la création de ces derniers. Mais est-ce souhaitable?
changer un titre = le changer dans le manifest, pas forcément dans le fichier
je crée un tuto en interne et ne l'édite que via zds
tout est géré en interne, seul risque de doublon : nommage de deux chapitres de la même manière lors de la création de ces derniers. Mais est-ce souhaitable?
Donc voilà : vous voulez absolument créer des choses ultra complexes (j'ai même vu quelqu'un qui veut absolument respecter les principes ACID) alors que je ne suis pas sûr que les cas d'utilisations qui nécessitent ACID soient les nôtres.
Sérieusement : est-ce vraiment possible d'avoir deux extraits de suite qui ont le même titre?
Enfin, actuellement, on stocke l'information du titre des extraits/conteneurs deux fois :
dans le manifeste :
champ title:"titre"
champ chemin des extraits text:chemin relatif à la racine du tuto
dans la convention de nommage
nom du fichier = pk_slug.md
On voit déjà actuellement que comme on stocke la pk et le slug, il y a perte d'info sur le titre.
A mon sens, on doit pouvoir garder libre la manière de nommer le path (à condition que pas d'accent pour pas faire sauter le file system à chaque fois).
Puis que de toute façon l'info est stockée dans le manifest.json, on a juste à stocker
{"title":"3D temps réel avec Irrlicht","description":"3D temps réel avec Irrlicht","type":"BIG","content":[{"type":"extrait","title":"Introduction","path":"introduction.md"},{"type":"extrait","title":"Conclusion","path":"conclusion.md"},{"title":"Une grande section","type":"section","path":"section1""content":[{"title":"Introduction","type":"extrait","path":"section1/introduction.md"},{"title":"un peu de contenu","type":"extrait","path":"section1/contenu.md"},]}]}
manifest.json big tuto
Mon exemple ne vas pas sur trois niveau hiérarchique car c'est trop long à écrire, mais le principe est là.
Justement, je pense qu'avoir une clé introduction et conclusion, qui pointe juste sur un extrait banal choisi, permet de donner un sens sémantique à ces extraits. Car là, avec ta proposition, il y a un risque de méler le statut de conteneur et d'extrait d'un élément. Comment faire la différence entre l'intro et la conclu, et un simple contenu en fait ? etc
D'où l'intérêt très claire, pour un conteneur, d'avoir en fait possiblement (pas obligatoirement) une intro, une conclu, et du contenu (réparti en conteneur ou simple extrait). Et donc le schéma proposé par Alex-D ou le mien, qui sont en fait équivalents.
@arrtragis: Concernant ta première remarque, dans le cas ou tout est géré via le site, oui, il est possible d'avoir des cas de recouvrement, parce que le nom du fichier est basé sur le slug. Déjà, il y a ce qui a amené Firm1 à rajouter à l'époque le pk dans le nom du fichier, c'est à dire qu'on pouvait nommer une section "conclusion" et ainsi écraser le fichier qui faisait office de conclusion.
Mais pas que. Il faut imaginer que l'auteur va forcément trouver un cas ou c'est nécessaire, même si j'en ai pas en tête ici qui soit concrètement réaliste, l'utilisateur est roi (surtout ici), donc il faut se prémunir de ce genre de chose. Loin de moi l'idée de pousser jusqu'à ACID, le système de hash me semble amplement suffisant pour éviter les éventuelles colisions. Et comme tu le dis, dans le cas ou c'est l'utilisateur qui gère lui même son organisation, rien ne l'oblige à faire pareil, puisqu'il est physiquement contraint à ne pas faire de doublon … Chance que n'as pas l'auteur qui passe par le site, et qui n'est pas forcément au courant de ce qui se passe en dessous.
Quand à la possibilité de laisser à l'utilisateur le pouvoir de gérer lui-même ces noms de fichiers, c'est une idée, mais franchement, je suis septique sur son utilité : le site devrait de touet façon prévenir que y'a doublon le cas échéant, et ce serait plus une perte de temps à gérer pour l'auteur comme pour le site (un commit à chaque fois, en plus). Ma politique sur le sujet, c'est "si tu veux gérer ta popote toi même, alors tu passes par git. Dans le cas contraire, autant rester simple et accessible".
Concernant ta seconde remarque, je n'ai pas exactement compris ou tu voulais en venir, bien que j'ai l'impression que tu réagissais sur la présence ou non de clé introduction/conclusion et en même temps faire écho à ta remarque précédente, même si la structure que tu proposes me semble valable.
Je te laisse répondre au remarques de Talus, parce que comme je l'ai dit, j'ai pas d'avis intéréssant à donner, d'autant que je suis pas forcément calé en spécifications JSON et que jusqu'ici, tout les arguments se valent (à part effectivement : comment faire la différence entre intro et conclusion, et comment rejeter les section de section à plus de deux extraits ?)
Bon, j'ai l'impression qu'on risque un peu de s'égarer par ici, je vais tenter (attention ça risque d'être long) d'expliquer pourquoi certaines choses sont obligatoire, et pourquoi tout ce qui fait beau sur le papier ne fait pas toujours très pratique.
L'introduction et la conclusion, pourquoi c'est important de les distinguer ?
D'après ce que j'ai lu ici, quelques uns veulent organiser un tutoriel sous la forme "un tutoriel est composé d'un ou plusieurs extraits et d'une ou plusieurs sections, les sections pouvant contenir un ou plusieurs extraits ou un ou plusieurs section".
Fonctionnellement, on a besoin à un moment ou a un autre de savoir clairement quelle est l'introduction d'une section, et quelle est sa conclusion. On ne peut pas juste décider que le premier extrait d'une section est forcément l'introduction et le dernier extrait forcément la conclusion, car l'introduction et la conclusion étant facultatif, on pourrait confondre un simple extrait d'une introduction.
Etant donné que dans l'affichage final il faut pouvoir identifier l'introduction et conclusion pour réussir à les afficher (uniquement eux) dans la présentation du plan d'un tutoriel, on à la la justification de leur existence.
Conclusion : Identifier l'introduction et la conclusion est important (cas particulier d'un type d'extrait).
Une clé d'identification d'un extrait ou d'une section, pourquoi est-ce obligatoire ?
Artragis, dans la description de ses cas pratiques, l'a montré, l'auteur a le droit de créer deux sections/extraits dont le titre est le même, on a la un gros risque de doublons potentiel, et ça serait une régression par rapport au système actuel.
La clé d'identification ne doit pas être un hash, car il est beaucoup trop long, et étant donné que cette clé d'identification doit figurer dans l'url de consultation d'une section, pour une section a 3 niveau on aurait une url d'extrait ultra longue et incompréhensible, comparée aux urls que l'on a aujourd'hui. De plus, si c'est un hash dans l'url, étant donné que le hash change en fonction du contenu, le jour de la publication d'un extrait, si on republie une mise à jour du tuto, le hash a changé et c'est mauvais pour le SEO.
Ensuite pourquoi la clé doit avoir des propriétés ACID ? Parce que
si pour la lecture d'un tutoriel on se base sur le slug contenu dans l'url, il suffit que deux tutoriels/sections/extraits ait le même slug pour que j'accède au tutoriel de quelqu'un d'autre.
un auteur peut avoir des co-auteurs, et là les choses se corsent un peu plus. En partant du principe que l'auteur A travaille sur l'éditeur en ligne et que l'auteur B travaille en local, si l'un décide de mettre à jour sa version en même temps que l'autre, bonjour les dégats transactionnels.
lorsqu'on voudra implémenter le déplacement d'un extrait d'un tutoriel à un autre, on sera bien embêté lorsqu'on se rendra compte qu'il y'a conflit entre les clés d'identification.
Ouvrir le dépot à la rédaction externe, qu'est ce que ça implique
Ouvrir le dépot n'est pas une tache anodine, et au delà des problèmes de sécurité entre les ranches (mais ça c'est la ZEP 8 qui devrait s'en charger), on a aussi pas mal d'impacts techniques liés à cette ZEP, à savoir :
L'auteur a le droit de structurer son dépot comme il le veut, et le site ne doit pas venir casser sa structure, ni la refuser, mais il doit s'adapter à sa structure, donc il faut que la technique s'adapte au modèle de l'auteur. ça peut aller du "je range tous les fichiers dans le même répertoire" à "je classe les extraits dans un seul dossier, les introductions dans un autre, et les conclusion à part".
Les images d'un tutoriel seront certainement envoyées dans un dossier par git push. Ceci dit, il faudra s'assurer dans les extraits de gérer les chemins relatifs
Inquiétude
J'ai cru comprendre que la base de donnée n'était pas envisagée, mais je rappelle tout de même que rechercher un extrait dans l'arborescence json d'un big tuto met environ 400ms (avec la meilleure lib de lecture json) alors que la recherche d'un extrait stocké dans une bd mets environ 10ms. Donc question perfs, on risque de pas être gaté si on fait uniquement de la gestion de fichier. A part écrire du code en C pour optimiser, je ne voit pas trop.
Voila quelques éléments que je juge important de solutionner pour cette ZEP.
Pour l'intro/ccl ça ne me dérange pas que ça soit un extrait à la sémentique différente et donc qu'on lui réserve une place particulière dans le json.
Fonctionnellement, on a besoin à un moment ou a un autre de savoir clairement quelle est l'introduction d'une section, et quelle est sa conclusion. On ne peut pas juste décider que le premier extrait d'une section est forcément l'introduction et le dernier extrait forcément la conclusion, car l'introduction et la conclusion étant facultatif, on pourrait confondre un simple extrait d'une introduction.
Oui et non. Je ne vais pas développer plus puisque de toute façon le consensus est au fait de mettre intro et ccl dans une clef spéciale.
Ouvrir le dépot à la rédaction externe, qu'est ce que ça implique
hors scope de cette ZEP
l'a montré, l'auteur a le droit de créer deux sections/extraits dont le titre est le même, on a la un gros risque de doublons potentiel, et ça serait une régression par rapport au système actuel.
Il n'y a risque de doublon que dans le cas où tout est créé par zds, dans le cas où la personne envoie le tout via un import, les doublons sont impossibles.
Pour nous les seuls vrais doublons qui puissent exister dans le cas nominal c'est un extrait appelé conclusion ou introduction ou tout titre qui donne comme slug conclusion ou introduction.
C'est pourquoi mon premier "fix" que j'avais pensé à l'époque c'était que pour ces deux extraits là : si la personne crée un extrait qui s'appelle "introduction" ou "conclusion", le fichier physique va se nommer p_introduction ou p_conclusion. Et ça marchait pas mal.
Hors du cas nominal, i.e les gens qui veulent faire chier le monde à créer sur zds (je le rappelle) deux extraits (ou plus) avec le même nom, dans la même section il suffit de vérifier dans la fonction "add_extract" que le fichier n'existe pas. Au cas où il existerait, on renvoie le formulaire en disant "un extrait possédant ce titre existe déjà". A mon sens c'est ça la vraie fonctionnalité désirée, pas celle actuelle où tu peux mettre cent extraits avec le même titre.
A mon sens la clef primaire est totalement inutile, le hash le serait aussi.
J'ai cru comprendre que la base de donnée n'était pas envisagée
puisqu'une fois le tuto publié la page d'arbo reste statique, pourquoi ne pas exporter le html comme on le fait habituellement pour les extraits?
Déjà, je note qu'on a à peu près un consensus sur l'emploi des clés intro/conclu, donc on avance
clé nominale/primaire/whatever, hash, pas hash ?
Pour moi, au contraire d'artragis, je pense que les problèmes de recouvrement vont plus loin qu'avec l'intro et la conclusion. Autant je vois effectivement mal l'utilisateur un extrait dont le slug tomberai justement sur p_introduction (d'ailleurs, c'est pas possible), ce qui veut pas dire non plus que c'est une bonne solution (pourquoi p_? est ce partie intégrante de la norme ou juste un truc de l'éditeur online pour se protéger ?), et j'était pas contre celle de Firm1 à l'époque, qui me semble tout à fait justifiée encore aujourd'hui.
Pour autant, comme le slug balance les caractères non-alphanumérique, on ne peut pas assurer qu'il n'y aura pas de recouvrement pour les noms d'extraits. J'ai du mal à trouver un exemple marquant, mais celui qui me vient à l'esprit (après 3 jours de recherches), ce serait un extrait dont le titre serait utilisation de { et } et un second qui serait utilisation de ? et :, qui donneraient à mon sens le même slug. Bien sur, mon exemple est complètement bancal, mais on ne peut pas exclure que ça puisse arriver, parce que l'auteur fait ce qu'il veut, donc pour moi, il faut une clé nominale.
Et il en faut d'autant plus une que je suis sensible à l'argument de Firm1 sur la recherche dans le JSON : au moment ou on se détachera de la base de donnée (j'en parle en dessous), il faudra d'une manière ou d'une autre qu'on valide l'url qui est donnée pour retourner le bon contenu. Si on commence à comparer les slugs de tout les sections de l'arborescence avec l'url, ça va être relativement long, il faut donc un truc un peu plus subtil, et c'est vrai qu'à ce niveau là, les pk étaient vachement pratiques, puisqu'il "suffisait" de faire un GET avec le bon pk et on était à peu près fixé, ce qui était vachement pratique. S'ouvre alors plusieurs options pour contourner ça :
On s'en fout, et tant pis pour la surcharge, on vire la clé nominale ;
On propose un mécanisme qui, comme le propose artragis, évite les recouvrements, et une fois encore, tant pis pour la clé nominale ;
J'avais proposé que à l'exportation, un arbre soit créé afin de faciliter la tache le cas échéant, on aurait qu'à parcourir cet arbre pour valider une url ;
On prend une clé nominale en forme de hash, mais j'avais pas réfléchi au fait que cette clé pouvais changer au cours du temps, il faut donc trouver un critère intelligent qui ne change pas ;
On reste attaché à la base de donnée, au moins pour ça.
Pour autant, l'argument de la longueur de cette clé nominale ne tient pas, malgré le fait que le hash me parait à réflexion une idée pas si bonne que ça. Un hash à 6 caractère me semble déjà une bonne sécurité, et rien ne dit que dans l'avenir, on ne va pas passer les 10000 chapitres (on est déjà au alentours de 4000), ce qui ferait une clé nominale qui, à un caractère près, ferai la même taille.
Pourquoi selon moi, la base de donnée n'est pas une bonne idée
Parce que.
Déjà, je précise que je ne suis pas pour un abandon total de la base de donnée, comme j'ai déjà du le dire à l'une ou l'autre reprise : il faut au moins donner un pk au tutoriel et conserver ses auteurs, ainsi que ces métadonnées tels que les hash des commits/branches, et ainsi de suite.
J'ai cependant peur que si on reste attaché à la base de donnée, on retombe dans le système actuel ou tout est stocké en base de donnée et on se retrouve avec des trucs abérants dont j'ai déjà parlé et qui m'as poussé à ouvrir cette ZEP (entre autre, le titre en base de donnée qui correspond à la version draft tandis que le titre en béta ou online sont pas les mêmes), et qui oblige une fois encore à perdre en factorisation par des appels exagérés à différentes chose. Même si on simplifie le mécanisme en balançant Part et Chapter et en les regroupant en une seule représentation unique (Section, à priori), si on continue à en stocker les informations en base de donnée, on court une fois encore à la catastrophe à mon sens : une base de donnée n'est pas fait pour stocker des objets versionnés, c'est bien pour ça que le site à choisi d'employer git.
Il y a aussi l'autre problème, que j'ai déjà fait remarquer à Firm sur sa PR concernant le ré-import de tuto : si on reste collé à la base de donnée, une Section ou un Extrait doivent obligatoirement avoir un pk, donc avoir été créé sur le site avant d'être modifié. Autrement dit, on perd l'avantage du travail en ligne ou tu fais ton tuto sur ton pc et ou tu push régulièrement des MàJ quand tu l'entend avec le contenu que tu l'entend : ça perd vachement de son intérêt. Je vais prendre mon propre cas : je suis en train d'écrire un tuto, et j'ai plus ou moins délimité la structure. Sauf que quand je l'écris, je me rend compte que y'a des choses qui doivent changer de place, être plus ou moins développée et ainsi de suite, mais je m'en rend compte PENDANT l'écriture du tutoriel, donc si on suis la logique, trop tard puisque j'ai déjà fixé ma structure en base de donnée et que je vais être obligé d'en passer par le site pour en changer.
Sans parler du cas inverse. Imaginons qu'on dise "non, t'es pas obligé de créer ta structure avant, le site s'adaptera à tes push" … Oui, mais quand ? Autant dans le cas du ré-import d'un zip, le site parcoure la structure de celui-ci et valide ce qu'il veut. Dans le cas d'un push à la git, le site n'en sais rien et n'est pas consulté dans le processus. Il faudrait alors un bouton "mettre à jour le JSON" qui rajouterai les pk là ou il n'y en a pas. Sans compter qu'il faudrait gérer le cas des Sections/Extraits qui deviendraient orphelins du jour au lendemain (supprimé dans le JSON par l'auteur mais pas en base de donnée car ça n'aurait pas été fait via le site) ou des multiposts (l'auteur ne prend pas la peine de faire un fecth du dépot après la mise à jour du JSON, ce qui aura pour effet de recréer des lignes en base de donnée au prochain appui sur le bouton).
Bref, énormément d'ennuis à gérer si on veux effectivement pouvoir laisser l'auteur travailler dans son coin avec git.
Clem' sous ACID
un auteur peut avoir des co-auteurs, et là les choses se corsent un peu plus. En partant du principe que l'auteur A travaille sur l'éditeur en ligne et que l'auteur B travaille en local, si l'un décide de mettre à jour sa version en même temps que l'autre, bonjour les dégats transactionnels.
lorsqu'on voudra implémenter le déplacement d'un extrait d'un tutoriel à un autre, on sera bien embêté lorsqu'on se rendra compte qu'il y'a conflit entre les clés d'identification.
Firm1
Pour moi, Firm1, tu oublies deux choses dans ce que tu dis, et la première est liée à la ZEP-8 : et git dans tout ça ? J'veux dire, déjà, git est ACID, enfin je l'espère (et si c'est pas le cas, on a plutôt intérêt à arrêter de discuter, ça n'as plus aucun intérêt), donc si recouvrement il y a, il y a toujours l'historique pour s'en sortir. Et puis quand bien même : si un auteur fait sa popote sur le site et un second de l'extérieur, à un moment, il va y avoir une opération de push. Et là, normalement, en cas de recouvrement, git va hurler au conflit (pull request, toussa), ce qui mettra la puce à l'oreille de l'auteur, normalement. Donc pour moi, ça, c'est pas un problème, clé nominale ou pas
Concernant le déplacement, j'ai du mal à voir en quoi c'est un problème : on peut toujours imaginer redonner un hash à cet extrait, puis la chance pour qu'il y aie deux hash identique est quand même vachement minime s'ils sont bien foutu
Le reste
puisqu'une fois le tuto publié la page d'arbo reste statique, pourquoi ne pas exporter le html comme on le fait habituellement pour les extraits?
artragis
+1 pour l'idée, je pense que c'est même déjà dans la ZEP (et si c'est pas le cas, ça le sera)
L'auteur a le droit de structurer son dépot comme il le veut, et le site ne doit pas venir casser sa structure, ni la refuser, mais il doit s'adapter à sa structure, donc il faut que la technique s'adapte au modèle de l'auteur. ça peut aller du "je range tous les fichiers dans le même répertoire" à "je classe les extraits dans un seul dossier, les introductions dans un autre, et les conclusion à part".
Firm1
Tant que les chemins dans le JSON sont relatif à l'origine, peu importe comment il les range. Là ou ça me pose plus de problème, c'est les gens qui ont un comportement différent que celui de l'éditeur du site (genre "tout dans un dossier") et ensuite qui repasse par l'éditeur du site pour rajouter un chapitre. Ça sera le bordel
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
