Et encore, t'as pas fait le coup de get_object() 
(sinon, sérieusement, très bonne nouvelle)
Voilà, les mixins sont implémentés, ce qui est vraiment un line saviour ^^.
En français, ça veut dire quoi ?
"économiseur de ligne". GLobalement, une 50aine sur ce qu'on a déjà porté et environ 50-75 autres qui devraient venir quand on aura tout fini.
Comme je le disais au départ, nous sommes en train de diviser non pas par 2, mais par plus de deux le nombre de lignes totales alors que nous avons gagné en fonctionnalités (sur les articles) et en performances. Le travail est long car il faut refaire tout le module et que certains codes sont un peu complexes à comprendre ou à recoder de zéro. Mais plus ça vient et plus on est content du résultat.
By the way, j'ai mis un "mixin" sur le get_object, et effectivement ça raccourcis encore le fichier !
Aujourd'hui, la partie la plus atomique d'un contenu1 est l'extrait. Cela signifie qu'il n'est pas possible de facilement faire référence à un élément plus petit qu'un extrait (paragraphe, phrase, mot…). Il pourrait être intéressant, pour prendre des notes, signaler une erreur… de pouvoir pointer vers des parties plus précises d'un contenu.
Pousser la granularité au niveau de la phrase ou du mot semble utopique et non nécessaire. Par contre, s'arrêter aux paragraphes est un bon compromis entre la précision extrême et celle faible des extraits. On ne leur donnerait pas d'url, juste un indice qu'on incrémenterait afin de générer une ancre et de pouvoir y faire référence via .../extrait#index.
Cette ZEP serait-elle concernée par ça ?
Tutoriel ou article. ↩
En fait il n'y a que le markdown qui peut extraire la structure. La mauvaise nouvelle est que actuellement ça demendrai beaucoup trop de bidouille, le parseur n'est pas du tout fait pour ça. La bonne nouvelle est que pandoc est lui parfaitement adapté et donc quand on l'utilisera je pourrait sortir une telle identification facilement : au niveau blocks (paragraphes, figures, …) jusqu'aux mots. Techniquement dans pandoc, chaque espace et chaque mot est dans un noeud dédié de l'ast.
Cette ZEP serait-elle concernée par ça ?
Non. PS : une petite démo avec des images devrait arriver ce midi.
En fait il n'y a que le markdown qui peut extraire la structure. La mauvaise nouvelle est que actuellement ça demendrai beaucoup trop de bidouille, le parseur n'est pas du tout fait pour ça. La bonne nouvelle est que pandoc est lui parfaitement adapté et donc quand on l'utilisera je pourrait sortir une telle identification facilement : au niveau blocks (paragraphes, figures, …) jusqu'aux mots. Techniquement dans pandoc, chaque espace et chaque mot est dans un noeud dédié de l'ast.
Tu vends du rêve Kje. J'ai hâte de voir pandoc devenir notre parser.
Après ça demandera forcément du travail, et pas que dans le parseur. Mais en soit ce sera techniquement possible de sortir une structure avec les éléments identifié. Il faut cependant apres que front et back les utilisent correctement. Mais bon c'est hors scope de cette zep, au moins a court terme.
au moins a court terme.
C'est hors scope tout court même si faut avouer qu'une fois cette ZEP mise en place, une partie non négligeable des verrous techniques actuels seront enlevés.
Oui et non. En fait rien n’empêcherai de le faire actuellement. C'est plus le parseur markdown le verrou actuel en réalité.
NB: je crois que je l'ai déjà dis mais je le redis - ne passez pas pas trop de temps pour faire l'assemblage des rendus html des différents extrait. Actuellement c'est crade mais la seule façon de le faire proprement c'est que ce soit le parseur qui s'en occupe. Et c'est prévu.
je crois que je l'ai déjà dis mais je le redis - ne passez pas pas trop de temps pour faire l'assemblage des rendus html des différents extrait. Actuellement c'est crade mais la seule façon de le faire proprement c'est que ce soit le parseur qui s'en occupe. Et c'est prévu.
En fait, dans mes souvenirs, on prévoit juste de faire passer le truc dans le filtre e-markdown pour créer le rendu et le mettre "en cache", on va pas faire un truc ultra complexe là dessus. Pour l'instant on veut juste améliorer la souplesse du système et ses performances qui sont vraiment mauvaises aujourd'hui.
En fait il n'y a que le markdown qui peut extraire la structure. La mauvaise nouvelle est que actuellement ça demendrai beaucoup trop de bidouille, le parseur n'est pas du tout fait pour ça. La bonne nouvelle est que pandoc est lui parfaitement adapté et donc quand on l'utilisera je pourrait sortir une telle identification facilement : au niveau blocks (paragraphes, figures, …) jusqu'aux mots. Techniquement dans pandoc, chaque espace et chaque mot est dans un noeud dédié de l'ast.
Projet Claire, ça vous dit quelque chose ?
Plus sérieusement, ok, c'est cool, mais on a déjà dit aussi que sur un texte en mouvement, ça allait pas être simple à manipuler 
Cette ZEP serait-elle concernée par ça ?
Non. PS : une petite démo avec des images devrait arriver ce midi.
+1 pour le "non". Et gros +1 pour les screens.
En fait, dans mes souvenirs, on prévoit juste de faire passer le truc dans le filtre e-markdown pour créer le rendu et le mettre "en cache", on va pas faire un truc ultra complexe là dessus. Pour l'instant on veut juste améliorer la souplesse du système et ses performances qui sont vraiment mauvaises aujourd'hui.
Exactement 
Et si on rédigeait un tuto?
Pour l'instant, nous n'avons pas encore fait la différence entre les articles et les tutos dans les différentes pages de liste, c'est prêt, mais les URLS n'ont pas encore été mises.
Commençons par ce que les gens connaissent :
La première différence arrive ici : lorsque vous rédigez un contenu, le format final importe peu, seul le type de contenu sémantique compte : est-ce un tutoriel ou un article?
Une fois cela fait, l'interface décidera pour vous si vous pouvez ajouter tel ou tel type d'élément, votre tutoriel étant vide, vous pouvez pour l'instant lui ajouter un "extrait" ou un "conteneur". Pour faire simple, ajoutons un extrait, pour créer un minituto, comme autre fois.
Vous trouverez alors que le bouton d'ajout d'un conteneur a disparu, en effet, nous sommes souples, certes, mais cohérent. Là on crée un mini tuto, à l'ancienne, il vous faudra ajouter des extraits au fur et à mesure.
Les articles actuels sont donc à voir comme des mini tuto avec un seul extrait mais avec une sémantique suffisamment différente pour qu'ils méritent une catégorie propre. Les articles v2 pourront avoir plusieurs extraits (et ça a été demandé) mais pas de conteneur, l'interface ne vous le proposera pas.
Si nous voulons un tuto plus organisé, ou du moins sur le modèle des Big tuto d'antan, il vous faudra créer un conteneur (avec intro et conclusion :)), puis dans ce conteneur en recréer un.
Une fois le conteneur de deuxième niveau créé, il sera impossible de faire autre chose que d'ajouter des extraits
Oui, mais, un contenu n'a pas forcément besoin d'aller à deux niveaux de précisions, alors nous pouvons faire des "Moyens tuto" sur lequel les conteneurs ne seront que du premier niveau (anciennement connus sous le nom de parties).
Nota : dès que vous créez un extrait dans un conteneur, ce dernier ne peut plus contenir de conteneur, vous ne pourrez ajouter que des extraits.
Surtout, imaginons que vous avez un big tuto très complet, mais qu'à un moment, vous avez une "partie" qui possède une certaine quantité de contenu, mais qui n'a pas à être éclatée en chapitre, eh bien, c'est possible.
Super boulot, et ça avance plutot pas mal.
Cependant, le vocabulaire employé m'a un peu perturbé.
D'après ce que je vois, on mixe le terme "Conteneur" (visible dans la sidebar) avec les termes "Chapitres", "Parties", "Extrait". Je pense qu'il est préférable d'utiliser un vocabulaire qui reste lié à la rédaction. Je remplacerais donc le mot "Conteneur" par "Section" (ou autre, si on à mieux).
D'après ce que je vois dans le sommaire d'un moyen tuto, on a deux niveaux "Partie" et "Extrait". J'aurai tendance à dire que dans le cadre d'un moyen tuto, la notion de partie ne devrait pas exister, mais uniquement des chapitres.
D'après ce que je vois, on mixe le terme "Conteneur" (visible dans la sidebar) avec les termes "Chapitres", "Parties", "Extrait". Je pense qu'il est préférable d'utiliser un vocabulaire qui reste lié à la rédaction. Je remplacerais donc le mot "Conteneur" par "Section" (ou autre, si on à mieux).
Ca fait partie des choses à gérer, en effet.
D'après ce que je vois dans le sommaire d'un moyen tuto, on a deux niveaux "Partie" et "Extrait". J'aurai tendance à dire que dans le cadre d'un moyen tuto, la notion de partie ne devrait pas exister, mais uniquement des chapitres.
Ce n'est que mon exemple, j'ai mis des titres générique, j'aurai pu appler ça
| Titre exemple | titre réel |
|---|---|
| Partie 1 | JS c'est de la daube |
| Extrait 1 | Dur de bien coder |
| Extrait 2 | package manager pas stable |
| Partie 2 | Python c'est cool |
| Extrait 1 | C'est clair |
| Extrait 2 | et pip c'est compréhensible |
Je suis tout à fait d'accord avec Firm1, et j'attendais justement qu'artragis fasse ses screens pour en parler (parce que ça marche mieux sur des exemples concrets). Donc comme vous pouvez le voir, il y a effectivement un "petit soucis" de vocabulaire, sur lequel je n'arrive pas à proposer de solution: comme on ne sais pas à l'avance ce que l'auteur veut (puisqu'on ne lui a pas demandé), on ne peut pas transformer le bouton "ajouter un conteneur" (qui ne veux rien dire pour l'auteur lambda) par "ajouter un chapitre" ou "ajouter une partie", en tout cas pas tant qu'il n'as pas fait de choix lui-même (évidement, si il donne à son tutoriel la forme d'un moyen-tuto, on peut deviner que ce qu'il va ajouter, c'est des chapitres, mais voilà).
Du coup, effectivement penser à "section", ou autre chose si quelqu'un a une idée. Mais il faudrait qu'on fixe absolument ce soucis de vocabulaire, sinon on va rebuter les auteurs et avoir quelque chose qui perd en simplicité.
PS: vous pouvez également remarquer que le sommaire ce casse la figure sur les moyens tutos et les "tutos hybdrides", je sais, et que l'affichage des chapitres devrait laisser apparaître la structure de ceux-ci comme c'est le cas actuellement, je sais. Pour le premier point, faudra un jour que je demande à quelqu'un du front, parce que sinon je vais casser le JS/CSS (qui, soit dit au passage est actuellement en transition, ce pourquoi j'attend avant de le faire)
Ce n'est que mon exemple, j'ai mis des titres générique, j'aurai pu appler ça […] JS c'est de la daube
artragis
Ah ok, je comprend mieux. Oublie donc ma deuxième remarque
EDIT :
@pierre : Je pensais justement au terme "Section" parce que du coup on peut le rendre générique en disant "Section", "Sous-section", "Sous-sous-section", etc.. ça marche aussi avec le terme "Partie", "Sous-partie", etc.
Je suis pas sûrs d'avoir compris les limites que vous imposez donc je vais poser une question en utilisant le vocable actuellement utilisé pour les big-tuto : est ce qu'il est possible de faire un tuto qui contient d'abord un chapitre seul puis 3 parties qui contiennent chacunes plusieurs chapitres ?
Je pose ca parce que ce serait pratique. Par exemple pour un big tuto ou l'intro est trop grosse pour rentrer dans l'extrait d'intro mais qui est trop petite pour etre découpé en plusieurs chapitre est un cas courant. Dans les livres ou gros contenu publié il n'est pas rares de voir des chapitres placé "hors de parties". C'est particulièrement vrai en début ou fin de document.
Je suis pas sûrs d'avoir compris les limites que vous imposez donc je vais poser une question en utilisant le vocable actuellement utilisé pour les big-tuto : est ce qu'il est possible de faire un tuto qui contient d'abord un chapitre seul puis 3 parties qui contiennent chacunes plusieurs chapitres ?
C'est tout à fait possible, et c'est même déjà possible en pratique.
Je pose ca parce que ce serait pratique. Par exemple pour un big tuto ou l'intro est trop grosse pour rentrer dans l'extrait d'intro mais qui est trop petite pour etre découpé en plusieurs chapitre est un cas courant. Dans les livres ou gros contenu publié il n'est pas rares de voir des chapitres placé "hors de parties". C'est particulièrement vrai en début ou fin de document.
J'y avais pas pensé, mais en effet, ça existe déjà ailleurs. Parfait (par contre, ça sera moins drôle à la génération du PDF ou du HTML, à mon avis, mais ça c'est pas pour tout de suite)
J'y avais pas pensé, mais en effet, ça existe déjà ailleurs. Parfait
Pas spécialement. Un chapitre hors partie c'est direct en début. En fin/milieu de doc c'est un poil plus chiant mais ça se fait, je l'ai déjà fait en tout cas.
Je suis pas sûrs d'avoir compris les limites que vous imposez donc je vais poser une question en utilisant le vocable actuellement utilisé pour les big-tuto : est ce qu'il est possible de faire un tuto qui contient d'abord un chapitre seul puis 3 parties qui contiennent chacunes plusieurs chapitres ?
Je pose ca parce que ce serait pratique. Par exemple pour un big tuto ou l'intro est trop grosse pour rentrer dans l'extrait d'intro mais qui est trop petite pour etre découpé en plusieurs chapitre est un cas courant. Dans les livres ou gros contenu publié il n'est pas rares de voir des chapitres placé "hors de parties". C'est particulièrement vrai en début ou fin de document.
C'est ce que j'ai tenté d'expliqué dans la partie "hybride".
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
