release early, tout ça, :) mets ça dans un dépôt github (quand tu peux) pour ceux que ça intéresse :) 2013/8/4 Nicolas <nikrou77(a)gmail.com&gt; > > Bonjour à tous, > > je viens de terminer une première version d'un plugin permettant > d'utiliser Twig comme moteur de template à la place du moteur actuel. > Tout ceci sans modifier le core bien entendu. Je me suis largement > inspiré du code de Bruno. Je ne vais pas encore vous le livrer car il > me reste à ajouter des tests unitaires et je ne suis pas encore rentré > à la maison donc il va encore falloir patienter quelques jours. C'est > juste histoire de vous mettre l'eau à la bouche. > > Du coup si j'ai bien lu les messages (en diagonales) cela va devenir > une très bonne idée de livrer aussi un thème utilisant réellement > Twig. En effet le plugin traduit les templates actuels (dans > inc/public/default-templates) en template Twig mais sans toutes les > merveilleuses fonctionnalités de Twig. > > J'essaie de ne pas vous faire patienter 10 jours !!! > > a+ > Nicolas > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

mais là dans 5 minutes je pars en ballade !

Bonsoir à tous, chose promise, chose dûe. En voici donc une première version brute de décoffrage : - le dépôt git : https://github.com/nikrou/twigTpl - le plugin sur un billet : http://www.nikrou.net/post/2013/08/04/Utiliser-Twig-pour-vos-templates-do... - le lien direct vers le plugin : http://static.nikrou.net/public/plugin-twigTpl-0.1.0.zip

2013/8/5 Dsls <dsls(a)morefnu.org&gt; > A noter, et comme indiqué plus haut, le code pondu par la moulinette est > juste une passerelle permettant à Twig d'interpréter les anciens templates, > cela ne constituera pas un template "propre" et maintenable. > Si j'ai bien suivi : si on installe déjà maintenant le plugin de Nicolas, on peut commencer à développper un thème pour Dotclear en Twig et qui sera conforme à ce qu'il faut faire pour les futures versions de Dotclear. J'ai tout bon là ? julien -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

2013/8/5 Dsls <dsls(a)morefnu.org&gt; A noter, et comme indiqué plus haut, le code pondu par la moulinette est > juste une passerelle permettant à Twig d'interpréter les anciens templates, > cela ne constituera pas un template "propre" et maintenable. > Si j'ai bien suivi : si on installe déjà maintenant le plugin de Nicolas, on peut commencer à développper un thème pour Dotclear en Twig et qui sera conforme à ce qu'il faut faire pour les futures versions de Dotclear. J'ai tout bon là ?

Quand tu parles d’ « exposer » les objets natifs, j’espère tout de même que tu envisages une forme de « façade » et pas l’objet du core

Quand tu parles d’ « exposer » les objets natifs, j’espère tout de même que tu envisages une forme de « façade » et pas l’objet du core directement ?

Ah ben le voilà le fameux et légendaire Dotclear "Sexy" : celui qui expose son core :p

* Un template dc ancienne sauce trituré pour Twig : {% dcBlock Entries={"lastn":5} %} {% dcValue EntryTitle %} {% enddcBlock %} * Un template twig : {% set posts = blog.getPosts({"lastn":5}) %} {% for p in posts %} {{p.post_title}} {% endfor %}

2013/8/5 Lepeltier kévin <kevin(a)lepeltier.info&gt; > > * Un template dc ancienne sauce trituré pour Twig : >> {% dcBlock Entries={"lastn":5} %} >> {% dcValue EntryTitle %} >> {% enddcBlock %} >> >> * Un template twig : >> {% set posts = blog.getPosts({"lastn":5}) %} >> {% for p in posts %} >> {{p.post_title}} >> {% endfor %} >> > > Woua ! Qu'est-ce que c'est moche ! > Difficile à lire, complexe ... > J'avais crus comprend que l’intérêt de twig c'était une syntaxe proche de > celle déjà existante. > J'ai mal compris apparemment. > > Petite note positive, merci pour ce plugin de test. je vois vraiment pas l'intérêt du premier (sauf si les templates actuels ne passent plus et qu'il faut forcément passer une moulinette). En revanche le dernier est très plaisant je trouve, moi. -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Woua ! Qu'est-ce que c'est moche ! Difficile à lire, complexe ... J'avais crus comprend que l’intérêt de twig c'était une syntaxe proche de celle déjà existante. J'ai mal compris apparemment.

j'éspère que l'on va garder :! {% dcBlock Entries={"lastn":5} %} {% dcValue EntryTitle %} {% enddcBlock %} Pour les intégrateurs non codeur, ou simple utilisateur. Qui non pas demander à apprendre à programmer.

Pourtant, je ne suis pas chaud pour cette solution (transformer à la volée les anciennes templates).

Je suis plus d'accord pour créer une boîte de compatibilité pour les templates, avec une dépréciation des anciennes templates. Idem pour les plugins.

Pourquoi les plugins ? Personnes n'y a pensé ? Parce qu'une architecture avec Twig *implique* une architecture MVC ou HMVC donc de tout revoir.

La séparation de la vue (Twig) du reste *implique* un controleur qui implique lui même un model. A moins que je ne prenne des vessies pour des lanternes ;)

Sinon, pour le test, beau boulot, tu as dû t'arracher les cheveux pour le réaliser, à moins que tu ne sois dans la catégorie "Meilleur Que Moi" ;)

Re, > Pourtant, je ne suis pas chaud pour cette solution (transformer à la volée > les anciennes templates). Ce n'est qu'une solution temporaire pour montrer que c'est possible de le faire. Et c'est aussi pour cela que ce n'est qu'un plugin et pas intégrer au core. De plus les templates originels (dans inc/public/default-templates ou quel que soit l'endroit) sont transformés en template twig à la volée mais mis en cache. Si le template originel ne change pas, la transformation couteuse n'est pas faite et on parse directement le template twig (du php pur donc !) > Je suis plus d'accord pour créer une boîte de compatibilité pour les > templates, avec une dépréciation des anciennes templates. > > Idem pour les plugins. C'est ton avis et ça n'engage que toi ! :-) Quel est l'avis de ceux qui font des thèmes ? Le moteur de template actuel a plein de défauts mais je pense qu'il est plus simple à comprendre. On a une syntaxe proche d'une syntaxe html, au préfixe (espace de nom) tpl près. J'ai essayé de faire la même chose dans les templates twig généré mais ce n'est pas possible sauf au prix d'énormes modifs. Mais évidemment il va falloir réfléchir à ce qu'on propose dans les templates. On ne va pas proposer un accès à tout le core comme c'est le cas maintenant. Bruno proposait de faire des proxy. Je partage cet avis. > Pourquoi les plugins ? Personnes n'y a pensé ? Parce qu'une architecture > avec Twig *implique* une architecture MVC ou HMVC donc de tout revoir. Non je ne pense pas qu'il faille tout revoir. > La séparation de la vue (Twig) du reste *implique* un controleur qui implique > lui même un model. A moins que je ne prenne des vessies pour des lanternes > ;) Ce n'est pas aussi strict que cela. Ce que j'ai fait n'est pas forcément très loin de ce qu'on pourrait faire et présenter comme syntaxe exploitable par tout le monde. > Sinon, pour le test, beau boulot, tu as dû t'arracher les cheveux pour le > réaliser, à moins que tu ne sois dans la catégorie "Meilleur Que Moi" ;) Je connais bien Twig pour l'avoir trituré dans tous les sens, fais des extensions, modifier le compiltateur et le parseur. De plus Bruno avait déjà écrit (en 2010) les expressions régulières pour faire la transformation. a+ Nicolas -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Pour moi ce n'est pas du tout contradictoire (voire même complètement implémentable de cette façon). Mais il faut bien faire la nuance entre : * Les variables de contexte twig positionnées par le code php/l'urlhandler quand il connaît le contexte de la page (ex : pour category.html, les entrées en cours de la catégorie courante), en l'occurrrence ici POSTS * Les appels de méthodes dans le template directement, comme blog.getPosts() qui peu ou prou ressemble à l'actuel <tpl:Entries>

Pour moi ce n'est pas du tout contradictoire (voire même complètement implémentable de cette façon). Mais il faut bien faire la nuance entre : * Les variables de contexte twig positionnées par le code php/l'urlhandler quand il connaît le contexte de la page (ex : pour category.html, les entrées en cours de la catégorie courante), en l'occurrrence ici POSTS * Les appels de méthodes dans le template directement, comme blog.getPosts() qui peu ou prou ressemble à l'actuel <tpl:Entries>

1. approche prioritaire au plus simple pour l'utilisateur et le primo arrivant, 2. fournir une intro rassurante à la migration sous Twig 3. laisser de la souplesse derrière, mais en planquant au mieux l'éventuelle "complexité". En gros privilégier l'approche user-friendly à celle de "j'm'appelle Roro, chui barbu et tatoué".

Y'a pas moyen de faire plus simple qu'un blog.getDates(), vraiment ? "archives" par exemple, ça serait plus parlant et plus lisible.

> Ca ressemblerait à ça : Aux bourdes près, voilà à quoi ressemblerait le guide pour remplacer loopposition : http://fr.dotclear.org/documentation/playground/themes/tags/loopposition A noter, la conversion "brut de fonderie" n'a parfois pas de sens, j'ai mis les optimisations qui vont bien quand elles sont possibles en twig. -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 7 août 2013 15:42, Greg <popech(a)gmail.com&gt; a écrit : > > Bon, ça sort quand ? :) Si ça ne tient qu'à moi, pas avant plusieurs mois (mais je ne suis pas seule à décider).

Tu fais référence au else ?

{% for POST in LISTPOSTS%} {{POST.post_content}} {{ POST.post_title}} ( Ce double post "POST.post_.." est dommage, mais c'est ce qu'il y a en bdd je pense )

Et sur la partie "Afficher uniquement les deux derniers billets" Je pense que ce serait plus lisible de séparer les deux version de twig, dans deux zones de code. -- Pour plus de clarté, je pense que ce serait bien de faire indépendamment l'explication pour header et pour footer.

Ça me fait penser à un truc. La plupart du temps quand je cherche une info dans la doc en rapport avec les balises, je demande à google "<tpl:" et je tombe sur la doc. Ensuite je consulte la liste des balises pour trouver celle qui me conviens. (puis je grogne et j’installe expat :) )

Et une autre qui traitera ... de quoi ? La liste des objets a disposition dans chaque contexte/url et un morceau de doc de Twig ou un lien vers Twig ?

Euh, ok, mais y'a vraiment pas moyen d'avoir quelque chose de plus lisible, genre : post.title à la place de p.post_title post.content à la place de p.post_content ?

Quand à loop.revindex1 je cherche encore à quoi ça fait référence. :-p

> On peut/pourrait. Dans mon esprit, on récupère directement un record > (au sens clearbricks du terme), et pointe sur la colonne en base. Pour > être propre, il faudrait même mettre p.getContent(). Je la refais : p.content devrait fonctionner. C'est à la fois un coup de chance, et un coup de pouce de Twig. Un coup de chance car le resultset des billets définit la méthode getContent. Un coup de pouce de Twig, car voyant que la méthode content n'existe pas, twig teste si la méthode getContent() existe. -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

De toutes façons, les intégrateurs, ils ne font que repomper des trucs qu'ils trouvent déjà faits ailleurs, donc il n'y a pas de problème :] </troll>

Sur les conseils de Pep, j'ai jeté un oeil sur Pelican. Les balises me semblent beaucoup plus friendly que les exemples que vous avez donnés jusqu'à présent et il y a des trucs qu'on n'a pas besoin d'écrire (genre on est dans une catégorie, le template le "sait") https://github.com/getpelican/pelican/tree/master/pelican/themes/simple/t...

Au plus je trifouille dans le code de twig, au plus je me dis qu'on devrait pouvoir faire un bouzin qui génère des templates twig propres. Après tout, on a déjà un parser de templates legacy qui construit un joli arbre qui contient tout ce qu'il faut pour traduire, il suffit ensuite de faire une moulinette par balise qui pond le code twig qui va bien.

Au plus je trifouille dans le code de twig, au plus je me dis qu'on devrait pouvoir faire un bouzin qui génère des templates twig propres. Après tout, on a déjà un parser de templates legacy qui construit un joli arbre qui contient tout ce qu'il faut pour traduire, il suffit ensuite de faire une moulinette par balise qui pond le code twig qui va bien. Et comme on parcourt un arbre en profondeur, on peut même compenser la notion de piles de variables du contexte, en gérant des incréments de variable (p, p2, p3, ...) qui vont bien. Restera alors la partie héritage qui sera peut-être plus touchy. La doc sur le dokuwiki de dotclear sera donc utilisée in situ :) Restera ensuite un plugin à faire, du type "is my theme twig-ready" qui vérifiera que toutes les balises utilisées par le thème en question seront bien traduites. Quant aux widgets, ils seront carrément plus simples à gérer (et un plugin de plus à casser) : 1 widget == 1 block twig, il suffit d'en définir les variables qui seront transmises par le contexte. Plus besoin de templatewidgets :) -- Bruno

> Ça a l'air bon ce que tu prépare, le fumer chatouille mais narines. le fumier tu voulais dire ? Chacun a ses odeurs préférées ! :-)