ZEP-12 : refonte du principe des tutoriels et articles

Avec pour base atomique ... l'extrait

L’auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Reprise du dernier message de la page précédente

qui revient aussi à de l'accès disque

les bdd travaillent beaucoup en mémoire et savent mettre des data en cache !

Je sais, mais c'est dans le pire des cas :)

Ce qu'il faut optimiser, c'est le nombre de fichiers à lire. Par exemple, lors de la publication, il faut faire un fichier par conteneur et non pas un fichier pour le conteneur + 1 par extrait.

+1000 !

artragis

Encore +1000 :)

Et question d'avancer, quid de cette histoire d'intro/conclu? Le seul probleme que je vois a "tout est un extrait" c'est que ceux la serait indéplacables et n'auraient pas de titre. Dans un soucis de généricité, ca fait un cas particulier :)

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+0 -0

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.

+0 -0

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

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.

Édité par Alex-D

Auteur du sujet

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.

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+0 -0

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à !

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+0 -0
Auteur du sujet

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 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à !

Talus

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

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+0 -0

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

Talus

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

pierre_24

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 ?)

Édité par Talus

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+0 -0

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"
        }
    ]
}

Édité par Alex-D

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.

Édité par Talus

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+0 -0

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.

Édité par Alex-D

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.

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+0 -0
Auteur du sujet

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é :)

Édité par pierre_24

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+0 -0

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.

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+0 -0
Auteur du sujet

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.

Édité par pierre_24

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

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