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

Je suis d'accord aussi ici avec Talus. Pourquoi a-ton besoin du slug dans un extrait ? Puisque au final le slug ne sert que pour le chemin physique, on a quelque chose comme ça :

1
2
3
4
5
6

       {
          type : "extract",
          title : "titre de mon extrait",
          slug : "titre-de-mon-extrait",
          text : "titre-de-mon-chapitre/titre-de-mon-extrait.md"
        },

le slug fait donc doublon ici car on le retrouve déjà dans la valeur de la clé "text". ça ne fait que rajouter des trucs à modifier pour l'auteur qui aura besoin de passer par l’extérieur.

Quelle url aura l'extrait du coup ?

L'url d'un extrait (comme aujourd'hui) est la même que l'url de son chapitre associé à une ancre. Par exemple, l'url associé à l'extrait "Et un peu de code" est la suivante tutoriels/399/creez-un-navigateur-web-en-net/#4-et-un-peu-de-code

Oui, mais "4-et-un-peu-de-code", c'est le slug, non ?

Pourquoi a-ton besoin du slug dans un extrait ? Puisque au final le slug ne sert que pour le chemin physique.

Ouais, mais si vous commencez comme ça, l'argument tient aussi pour un conteneur, non ?

J'admet ceci dit que c'est redondant dans le manifest.json. Je dis et je martèle qu'on en a besoin par ailleurs. À préciser également que ce nom de fichier DOIT se conformer aux règles de formation d'un slug pour ces mêmes raisons.

Et si vous me dite encore "non, va mourrir avec ton slug pour les extraits", alors vous devez me présenter un morceau de code qui fait pas de isfile() et qui assure que le nom du fichier de l'extrait est bien unique.

oui c'est le slug, mais lui il n'a pas besoin d'être dans le fichier manifest puisqu'on peut le déduire depuis text : "titre-de-mon-chapitre/titre-de-mon-extrait.md"

J'aimerai bien savoir ou (vraie question), car je ne le vois pas.

Imaginons qu'on ait plus que :

1
2
3
4
5

       {
          type : "extract",
          title : "titre de mon extrait",
          text : "titre-de-mon-chapitre/titre-de-mon-extrait.md"
        },

pour connaitre le slug, il te suffit d'avoir une fonction du genre :

1
2
3
4

def get_slug(text)
{
    return text.split('/')[-1][:3]
}

A ce compte-là, on peut aussi enlever le champ text et le déduire de la concaténation des champs title des parents et de l'objet, non ?

Par contre, pour enlever le ".md", c'est pas [:3] qu'il faut faire.

@firm1: Quand je disais "par ailleurs", c'était qu'à un moment, il fallait qu'on le connaisse. C'est évidement à ça que je pensais, allons donc

A ce compte-là, on peut aussi enlever le champ text et le déduire de la concaténation des champs title des parents et de l'objet, non ?

Noooooon, parce que deux extraits peuvent conduire au même slug. C'est si compliqué que ça à comprendre, vraiment ?!?

on a le droit à path.exists()?

Sinon, actuellement nous rangeons les extraits dans l'ordre. C'est cool, mais ne peut-on pas imaginer de les mettre plutôt dans le style :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

tuto{
méta données blabla

children{
    "partie1":{
         "title": "partie 1",
         "object-type": "Container",
         "place-in-parent": 1,
         "children":{
             "extrait1":{
                //bref vous avez compris
              }
         }
     },

    }

}

Ah oui, donc tu rajouterais le compteur dans le champ text (enfin, il doit déjà y être : tu devrais compléter l'exemple de manifest.json du premier message) ?

Et la contrainte d'avoir un slug unique dans le contenu, c'est juste au cas où on souhaiterait déplacer un extrait/conteneur dans un conteneur ayant déjà un objet portant ce titre ?

@astragis : quels en seraient les avantages ? Pour mettre le slug en clé du dictionnaire plutôt que dans un champ slug ?

On peut. Qu'est ce que ça apporterai ?

(sachant qu'autant l'accès à un dico est en $\mathcal{O}(1)$, autant faire un crawl systématique sur des clés dessus est plus coûteux quand on lit le fichier json, en $\mathcal{O}(2n)$ ou un truc du genre).

EDIT: Ouais, m'enfin faut commencer à gerer place-in-parent, à refuser des manifests quand ils sont la même valeur pour ce champ … Et ça oblige à préciser le slug, tout compte fait, faudrait savoir.

on a le droit à path.exists()?

Nan. Pas de lecture disque inutile, un max dans le manifest.

@astragis : quels en seraient les avantages ? Pour mettre le slug en clé du dictionnaire plutôt que dans un champ slug

l'avantage?

1
2
3

obj = json_deserialize(manifest_content);
container_lvl1_exists = slug_container_lvl1 in obj['children']
container_lvl2_exists = slug_container_lvl2 in obj['children'][slug_container_lvl1]['children']

ce n'est qu'une proposition. Au moins on a retourné le problème dans tous les sens, histoire que notre choix soit fait en connaissance de cause et qu'on doive pas faire une ZEP 42 qui revient sur le boulot de la ZEP12

Synthétisme, toussa toussa

Je n'ai pas dit qu'il fallait le générer a tort et a travers… A la rigueur, si le fichier introduction (resp conclusion) existe pas, soit on utilise celui-ci. Sinon un hash ; en gros, on ne râle pas si ça existe déjà. A la rigueur, la solution de pierre, mais bon, c'est le même bordel avec ou sans (quand viendra la zep-8 - oui je l'ai toujours en tête celle-là, même s'il en est pas question ici), alors qu'un hash généré, il y a encore moins de chance d'avoir un même nom de fichier (rien que pour 5 caractères générés, on a une chance sur 9765625… alors qu'un #intro, intro, … vu que c'est mot intelligible, y'a déjà plus de proba de tomber dessus !)

Et comme c'est déjà une chance minime d'avoir deux fois introduction au sein d'un même container` (et encore, je parle d'enfant directs !), le truc des hash risque de se produire une fois sur - disons - 1000, la première solution devrait convenir la plupart du temps. Et encore, ce genre de calculs ne devrait être fait que si on utilise l'éditeur du site et que* lors de l'écriture du dit tuto !

Yup yup yup. Unicité non pas vis à vis du container root, mais du container parent (juste), toussa toussa. C'est ce que j'ai déjà dit à plusieurs reprises.

je demande justement le contraire : pourquoi le slug est-il unique de manière globale et non pas juste par rapport à son parent direct ?

Cf mon premier blabla dans ce premier message <3

Non malheureux ! Le but de cette propriété est (toujours en adéquation avec la zep-8, travail a part, etc, …) de pouvoir indiquer où trouver le fichier et ne pas contraindre une orga !

je demande justement le contraire : pourquoi le slug est-il unique de manière globale et non pas juste par rapport à son parent direct ?

C'est le DTC qui l'a dit et en plus ça simplifie tellement les choses…

@artragis : C'est déjà ce que je fini par faire, j'ai children qui est une liste pour quand j'ai besoin de faire des for dessus (faire une màj, deviner un sommaire, toussa) et children_dic pour les accès en $\mathcal{O}(1)$ sur un enfant bien précis (résoudre une url, toussa). L'un ou l'autre ne me pose pas de problème, sauf que ta fonction deserialize_json() retourne un dico. Ok, mais à un moment, faut le faire rentrer dans un objet, et faire un

1
2

for child in obj['children'].keys() : # opération moins rapide que sur la liste correspondante, dixit la doc
  container = child # c'est plus complexe que ça, évidement ^^

Sachant qu'un manifest se lit souvent … Une liste me semble appropriée.

@Talus: Raaaaaaaaaah, je te comprend toujours de travers Hum. Bon.

Je résume: pour toi, une introduction ou n'importe quel extrait devrait s'apeller par un hash, c'est ça ? (commence par répondre par oui ou par non, s'il te plait, tes réponses sont super ambigues )

Pour le slug unique par rapport à quoi, artragis a répondu.

Oui mais ça pose des contraintes. Y'a t-il une vraie raison pour ça ? Il faut penser "utilisateur" par forcément "developpeur" ici. Car c'est l'utilisateur qu'il faut satisfaire

À priori, je n'ai pas trouvé de raison valable pour que le slug ne soit pas unique uniquement de manière locale, d'autant si on fait du children[key].children[key].children[key]. Je cherche ceci dit pour être sur.

Non. Il devrait pouvoir s'appeler par un hash, si le nom / slug est déjà pris.

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é.

Il peut s’appeler comme il veut en même temps. Pourquoi un hash et pas introduction-1.md, par contre ? (sachant que chronologiquement, l'introduction est créé avant le texte, donc c'est lui qui à la primauté).

Oui, peu importe. Ce que je reprochais c'est le blocage de ces noms, qui n'a pas lieu.