Et pour le slug, comme ça déjà été mentionné, pourquoi ne pas générer une sorte de path via le manifest + les titles qu'on transforme en slug ?
Parce que si pour une raison deux etraits ont le même slug dans le même conteneur (oui, c'est tordu mais ça peut arriver), on a de la collision quand même. Ou j'ai pas compris (en plus du fait que ça va faire des slugs supers-longs )
Sauf que je doute que quelqu'un utilise deux fois le meme titre au sein d'un même parent direct… Et au pire, LIFO. Et osef des titres longs ; il est plus facile de divulguer /tuto/tuto-cool/partie-cool/#sous-partie-cool que /tuto/asjv29-3554b-sgv-dt-4543-fbfdgrdd/4533-lbbngrde/#fjeiofjes, non ?
Ah mais je parlais du type de tuto, pas du conteneur. Du coup pour l'instant je viens de comprendre la diff entre "type" et "obj_type", mais en effet, si on extrapole (au pire, indiquer qu'on peut renseigner le type du tuto, qui prend alors précédence, avec une validation - un mini-tuto ne peut pas avoir de sous-conteneur, tout comme un moyen a besoin d'un (et un seul) conteneur, et un big d'au moins un).
Je te corrige, mais on peut mettre plusieurs conteneur (=chapitre) dans un moyen tuto
Après clarification avec moi même (oui on est plusieurs là dedans :D), il faut voir si on a une et une seule conteneur en tant qu'enfant du root (donc enfant direct), mais après libre a ce sous-conteneur d'avoir plusieurs conteneurs… Un mini-tuto lui ne devrait avoir que des extracts, alors qu'un big-tuto doit avoir au moins un conteneur.
Mais après du coup, comment savoir, lorsqu'on lit un conteneur, s'il s'agit d'un type de tuto (s'il est root) ou bien d'un type de conteneur ?
Du coup, niveau nomenclature, je trouverai ça plus logique d'avoir une clé optionnelle "type" dans le conteneur root, qui définit le type du tuto (sinon il doit pouvoir être extrapolé), puis des clés "object", optionnelles (encore une fois, un truc extrapollable) aussi, qui indique le type de conteneur
Je te corrige, mais on peut mettre plusieurs conteneur (=chapitre) dans un moyen tuto
et je le redis, le but c'est même d'aller plus loin en terme de souplesse : tout conteneur peut contenir soit des extraits soit des conteneurs. Sachant que le conteneur de 2ème niveau ne peut pas avoir de conteneur pour éviter d'aller trop loin en profondeur.
À ceux qui aiment les pavés, je vous invite à lire ceci ou j'énonce les grands principes techniques et fonctionnels de la ZEP-12. J'ai fait exprès de le mettre dans un sujet séparé pour lui donner un peu plus de visibilité qu'enterré ici (ça concerne tout le monde, après tout).
Bon, juste pour le fun : j'ai réussi à afficher un tutoriel avec le système V2 :
En V1, pour rappel, on a ça :
Bref. Aucun lien ne fonctionne, l'URL ne ressemble à rien, j'ai du passer par l'interface d'admin pour rajouter le tuto à la main, j'ai du employer GIT à la main et générer le fichier JSON de même … Mais ça marche !
Bref. Aucun lien ne fonctionne, l'URL ne ressemble à rien, j'ai du passer par l'interface d'admin pour rajouter le tuto à la main, j'ai du employer GIT à la main et générer le fichier JSON de même … Mais ça marche !
haha, ça fait encore beaucoup de manipulation manuelle pour que ça fonctionne vraiment mais c'est déjà un bon gros pas en avant qui a de quoi motiver. Bravo les gars !
Parfait, les CBV sont vraiment géniales alors, c'est pas qu'une apparence.
haha, ça fait encore beaucoup de manipulation manuelle pour que ça fonctionne vraiment mais c'est déjà un bon gros pas en avant qui a de quoi motiver. Bravo les gars !
disons que rien dans l'écriture n'a été migré pour l'instant. mais ça devrait arriver.
Afin de faciliter le suivi de la ZEP 12 qui est un projet extrêmement ambitieux, j'ai créé un projet sur mon redmine perso. Il est accessible à cette adresse, vous devinerez que françois dambrine, c'est moi.
Si vous désirez modifier le redmine et participer aux discussions, va falloir créer un compte.
Je ne sais plus à qui et quand j'avais promis de faire de la comparaison, mais voilà une petite idée …
Ancien :
Nouveau :
Donc voilà. Malgré ce que laisse croire les captures, je dirais que les performances sont "comparables" (entre autre parce que il n'y a pas encore toute les anciennes possibilités dans le nouveau système, ceci dit, on gagne clairement sur l'affichage d'un "chapitre", comme espéré). Ce qui me "dérange" le plus est qu'en fait il y a quasiment autant de requête avec l'ancien ou le nouveau système, ce qui n'est pas forcément attendu, donc il va être nécessaire d'aller un peu nettoyer là dedans, à mon avis.
Super boulot, comme promis, je pourrai recommencer la semaine prochaine, sûrement mercredi aprem sauf si ma participation au concentré de savoir me prend plus de temps que prévu.
Je me demandais : pourquoi ne pas considérer qu'on a un ensemble d'extraits, puis ajouter des relations entre ces derniers ? On aurait des briques quasiment atomiques qu'il ne suffirait alors plus qu'à assembler pour obtenir un cours. Ce système serait alors extrêmement flexible et permettrait facilement de :
Factoriser le contenu
Comme souligné par bendia ici, certains tutoriels réfèrent à des notions communes. Plutôt que de se répéter, il serait intéressant de l'expliquer une fois et d'inclure l'explication dans le tutoriel.
Guider le lecteur
On pourrait avoir des embranchements plutôt qu'un truc linéaire. Ainsi, à la fin de la partie sur les fonctions d'un tutoriel Python, on pourrait :
Poursuivre le tutoriel si on est débutant
S'intéresser aux callbacks, puis aux décorateurs
S'intéresser aux générateurs
L'objectif est de conseiller le lecteur sur ses prochaines lectures en fonction de ce qu'il vient de consulter, de sorte qu'il sache quoi faire à la fin du tutoriel.
Créer des parcours
Globalement, il est plutôt simple de se documenter sur le Net : il foisonne de ressources. Le problème, c'est quand on ignore où commencer. Par exemple, le blog sametmax regorge d'explications très claires. Mais il n'y a pas de logique entre les articles, ce qui fait qu'il est très dur d'apprendre le Python de zéro là-bas. Avec le système de tuiles, il suffirait de relier les articles de sorte à donner une direction au lecteur.
En outre, comme on a les briques, si jamais le mur disponible sur le site ne nous convient pas, on peut assez facilement en construire un autre. Ca permettrait par exemple d'enseigner un langage de programmation d'une autre manière, sans avoir à refaire un tutoriel de A à Z.
Simple idée. J'ignore si c'est viable pédagogiquement, juridiquement et techniquement.
Simple idée. J'ignore si c'est viable pédagogiquement, juridiquement et techniquement.
c'est une idée que je vais développer dans un projet d'application pour ZDS. Mais il faut deux choses avant que je m'y mette :
du temps
la validation complète de l'API (au moins membres)
J'aurai un peu de temps en février pour coder la zep 12, j'aurai du temps (en grande quantité) dès mars pour faire plus de choses. A noter, avec un membre, nous sommes en train de faire la lib de contact de l'API pour .NET.
Ah, c'est pas à ça que je pensais. Je me disais surtout que sur les templates, y'avais à un moment :
1
2
3
4
5
6
7
{% if content.get_introduction and content.get_introduction != "None" %}
{{ content.get_introduction|emarkdown:is_js }}
{% elif not content.is_beta %}
<p class="ico-after warning">
{% trans "Il n'y a pas d'introduction" %}.
</p>
{% endif %}
Du coup, si c'est pas opti, il fait 3x appel à get_introduction(), qui revient à taper 3x dans le repo. Conclusion, faut aller faire un truc par là, et on peut gagner du temps
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
(en plus du fait que ça va faire des slugs supers-longs
)
