ZEP-12 : refonte du principe des tutoriels et articles

Quel est le problème à avoir un titre sur une intro / conclusion ? Perso je n'en vois pas.

Un titre pour une intro d'une partie (au sens actuel) tu le met a quel niveau de titre ? (C'est pas un piège )

Une partie = un conteneur qui contient des conteneur. Donc niveau 3. Car titre = 1, sous-titre = 2.

Donc au meme niveau que le titre des éventuels sous-conteneurs genre chapitre dans partie ? (Juste pour etre sur).

• Conteneur
  • Extrait
  • Conteneur
    • Extrait
    • Extrait
    • Extrait
  • Conteneur
    • Extrait
    • Extrait
    • Extrait
  • Extrait

On doit pouvoir faire ça. Mais en effet, pour limiter le bazar entre intro/conteneur/extrait/conclusion, faudrait peut-être bien en faire des extraits particuliers du coup :/

Non, je pense qu'il faut rester sur ton modèle Alex-D.

Ca sert à rien de faire un extrait "spécial" surtout qu'il n'est pas forcément rempli !

La seule chose qu'il faut gérer ça serait la demande de déplacement d'un conteneur dans un contenur que lui même contient : il faut interdire cela !
Pour la rédaction du contenu, il faut vraiment être très souple quitte à donner des conseils aux auteurs. La validation est aussi faite pour ça.

J'avais besoin que quelqu'un poste pour pouvoir me corriger

En fait, il faut imaginer l'interface. Côté modèle de donné on se base sur du

Conteneur > (Conteneur|Extrait)

Un conteneur contient des conteneur et des extraits.

Après, il faudra gérer les exceptions ailleurs : dans le back notamment, et en offrant une UI qui ne permette pas de faire les choses qu'on ne souhaite pas.

Exemple d'UI :

Conteneur vierge

Ajouter un extrait

Ajouter un conteneur

Conteneur ayant déjà des extraits

• Extrait 1
• Extrait 2

Ajouter un extrait

Conteneur ayant déjà un conteneur

Ajouter un extrait

• Conteneur existant

Ajouter un conteneur

Ajouter un extrait

Conteneur ayant déjà un conteneur et un extrait en guise d'intro

• Extrait "Introduction"

• Conteneur existant

Ajouter un conteneur

Ajouter un extrait

Conteneur ayant déjà un conteneur et un extrait en guise d'intro

• Extrait "Introduction"

• Conteneur existant

Ajouter un conteneur

• Extrait "Conclusion"

En prenant en compte une telle chose, alors on a plus de soucis à se faire.

Il faudra simplement empêcher "Ajouter un conteneur" à partir du niveau 2, et ce sera bon.

ça ve ma !

J'aime bien aussi. Je préciserait juste explicitement bien que cet extrait sert d'intro/conclusion a partir du moment ou le conteneur en contient un autre. Et il faut autoriser qu'ils n'aient pas de titre, pour la rétro-compatibilité. Par ailleurs,… Question code, il faudra les nommer d'une manière ou une autre. Ne serait-ce que pour savoir qui est l'intro et qui est la conclu.

Et il faut autoriser qu'ils n'aient pas de titre, pour la rétro-compatibilité

Non. Actuellement on sait quels blocs deviendront des intro et conclusions. On peut même forcer le titre pour ces deux blocs. Ou alors ne pas en mettre, pour tout ça est une question de rendu front, on fait ce qu'on veut tant qu'on peut les identifier.

En gros, il faut juste mettre une métadonnée pour savoir si c'est un conteneur mixte, ou un conteneur d'extrait. À partir de là, c'est dans la poche.

Ce que je pense, c'est que dans le manifest, on devrait pouvoir indiquer qu'est-ce qu'un conteneur, la liste de ses extraits (si y'en a) et leur chemin, ainsi que deux trucs spéciaux (en effet) type introductiobn: ./chemin et conclusion: ./chemin. En somme, dans l'arbre json, un conteneur ne peut que contenir ou bien des extraits ou bien des conteneurs. Il ne faut pas se décider à dire "ok on considère qu'un conteneur doit soit disposer d'une intro ET d'une conclusion, soit on considère que y'a ni l'un ni l'autre".

Je parle toujours dans l'optique d'un accès distant, même si c'est ici pas le sujet. Il faut aussi penser à cet aspect là !

Ce que je pense, c'est que dans le manifest, on devrait pouvoir indiquer qu'est-ce qu'un conteneur, la liste de ses extraits (si y'en a) et leur chemin, ainsi que deux trucs spéciaux (en effet) type introductiobn: ./chemin et conclusion: ./chemin. En somme, dans l'arbre json, un conteneur ne peut que contenir ou bien des extraits ou bien des conteneurs. Il ne faut pas se décider à dire "ok on considère qu'un conteneur doit soit disposer d'une intro ET d'une conclusion, soit on considère que y'a ni l'un ni l'autre".

J'ai un peu du mal à te suivre, sur ce coup là. T'aurais un exemple?

Je garde bien en tête l'aspect git et tout ce qu'il sous entend

Je ne connais pas très bien le modèle des manifest, mais en gros :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{// ...
 "content" : {"introduction": "./path/to.md",
              "conclusion": "./path/to.md",
              "title": "...",

              "children": [{"introduction": "...",
                            "title": "...",
                            "type": "container",
                            "children": [{"type": "extract",
                                          "title": "...",
                                          "path": "..."}]}]}}

En très très gros. Vu que le manifest sert un peu de sommaire, l'idée serait donc là : avoir deux types en effet d'éléments, soit un container, soit un extract. Evidemment, le premier container (la racine) est forcément un container. Mais pour un container, il peut contenir les clés introduction, conclusion, title, type et children. Evidemment, introduction, conclusion sont optionnelles. Pour un extract, il pourra contenir que title, type et path.

Ca permet ainsi une très grande flexibilité, et n'est pas non plus un enfer à maintenir (du moins je crois ?). Limite, pour la racine, on peut la considérer spéciale et ajouter genre une clé summary ou autre chose. Tout comme dans les meta data, on pourrait avoir genre la license par exemple ?

J'ai probablement oublié des clés à la con (genre les icones, …), mais l'idée est là. Il faut en somme spécifier un peu le contenu du manifest. Pour le cas des "introductions + conclusion", les unes peuvent vivre dans els autres. En gros, on doit permettre à quelqu'un de ne pas mettre l'un ou l'autre, au choix (limiter ça pour les big / middle tutos ?)

Du coup, exemple de manifest :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

{
    "title": "Créer des GIF animés", 
    "description": "Vous voulez des images qui bougent pour faire des LOLCAT ? C'est ici.", 
    "authors": [
        "Alex-D",
        "pierre_24"
    ],
    "license": "CC BY-SA",
    "image": "assets/tuto.png",
    // Toutes les metadonnées ici

    "introduction": "intro_du_tuto.md",
    "content": [
        {
            "title": "Créons notre première image animée",
            "introduction": "introduction.md",
            "content": [
                {
                    "title": "Les bases", 
                    "text": "les-bases.md"
                }, 
                {
                    "title": "Squelette du script", 
                    "text": "squelette-du-script.md"
                }, 
                {
                    "title": "Exemples", 
                    "text": "exemples.md"
                }
            ],
            "conclusion": "conclusion.md"
        },
        {
            "title": "Une autre partie du cours",
            "introduction": "introduction_part2.md",
            "content": [
                {
                    "title": "Premier chapitre de la mort",
                    "introduction": "introduction_de_la_mort.md",
                    "content": [
                        {
                            "title": "Les bases 2", 
                            "text": "les-bases.md"
                        }, 
                        {
                            "title": "Aller cer party", 
                            "text": "squelette-du-script.md"
                        }
                    ],
                    "conclusion": "conclusion_de_la_mort.md"
                }
            ],
            "conclusion": "conclusion_part2.md"
        }
    ]
}

Je suis pas sûr de la pertinence de stocker les auteurs dans le manifest perso. Mais en gros ta structure ne change pas grand chose, mis à part que t'as renommé certaines clés (que je trouve du coup moins pertinentes : un container a des enfant, pas du contenu qui peut être soit des container soit des extraits ; tout comme je pense qu'il faut que les différents éléments sachent de quels type ils sont sans essayer d'observer la structure, source certaine d'erreurs, ou la propriété path qui montre… bah un chemin. Au lieu d'un text, qui n'en es pas un, vu que c'est un chemin vers un fichier. De texte certes, mais ça reste un chemin).

Mais l'idée serait là oui.

contenu qui peut être soit des container soit des extraits

C'est l'idée de base en fait… sinon ça ne sert à rien de tout refaire.

un container a des enfant, pas du contenu

Au point où on en est : on s'en fou.

il faut que les différents éléments sachent de quels type ils sont

Aucun intérêt. Dans mon exemple, array = container et object = extrait c'est donc implicite par son type.

Sauf que je sais pas si t'as vu, mais chaque enfant est un objet hein. C'est juste que l'un contient des enfants, et l'autre non.

Bien sur que c'est l'idée de base, je te dis juste que les noms des clés sont pas adaptées, c'est tout.

Je ne sais pas ce que ça implique au niveau technique mais il serait bien de pouvoir aussi rajouter les parties d'un tuto dans un autre, ou détacher certaines parties d'un tuto pour en faire un tuto à part. Ça peut servir si on veut ne faire valider ou mettre en bêta qu'une partie du tuto.

Bon, pour avancer :

• Pour les auteurs du tutoriel dans le manifest.json, je suis partagé. Autant je reconnait que ça peut être bien pour des histoires de versionnage et ainsi de suite (encore que Talus, sur la zep08, proposait de regarder les auteurs de la branche), autant je vois venir les complications si un jour un auteur vient à changer de pseudo ou disparaitre (ce dernier cas étant relativement plus simple à traiter, cela dit). Dans tout les cas, stocké comme ça, ça obligera probablement à une recherche en texte pour chaque auteur dans la base de donnée, donc je stockerai d'une manière ou d'une autre le pk de l'user avec.

• Pour les conventions de nommage des clés : vous avez tout les deux à peu près la même idée. En gros, ce que vous dite, c'est

  • Le premier conteneur contiendrait avec lui toute les métadonnées (et non un éventuel objet Document) ;
  • Un conteneur à pour clé title, introduction, conclusion et une clé pour ces enfants (conteneurs ou pas) ;
  • Un Extrait à une clé title et chemin vers le fichier.

  Si je doit reprendre les différences, y'a la clé contenant les enfants : childreen/content, la clé du chemin vers le fichier markdown : text/path et le fait que Talus propose une clé type.

  Objectivement, j'ai pas d'avis sur le sujet, sauf que text est la clé "historique" utilisée actuellement (argument qui en vaut un autre). Je pense qu'il faut surtout que ces clés, telles qu'elles soient, aie un nom évident qui permettent d’éventuellement pas trop se casser la tête si on doit éditer le fichier à la main. À ce niveau là, je pencherai vers content, mais ça n'engage que moi ^^. Quand à la clé type, faut réfléchir en terme de performance, en l'absence d'argument estétiques : est ce que il est plus rapide de faire un test sur champ que de regarder si une clé existe dans un dictionnaire ? (en l’occurrence ici la clé childreen/content).

• Pour la remarque de Looping : à mon avis, t'aura plus de chance du coté de la ZEP-08 : j'entend bien ce que tu dis, mais pour moi, ce que tu exprime reviens à un moment à choisir ce que tu envois en validation, qui n'est pas forcément l'entièreté de ton tutoriel, et ça, ça a pour moi plus de sens d'en discuter à coté

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.

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.

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.