Re: [Dotclear Dev] Twig : le topo
by Jean-Christian Denis
Question idiote: côté publique c'est le thème qui fait ses formulaires (a l'ancienne) pourquoi ne ferait-on pas pareil côté admin? Ça serait vachement moins usine a gaz quand même.
Dsls <dsls(a)morefnu.org> a écrit :
>Hello,
>
>Ci-dessous mes avancements sur le sujet twig. A l'ordre du jour :
>
>Concernant la lib : j'ai bossé sur la v1.6.3, il faudrait voir ce
>qu'il faut adapter pour la v1.11.1 toute fraîche. Elle est positionnée
>dans inc/lib/twig
>Coté admin, Twig tout seul ne suffit pas/ne résoudra pas forcément
>tous nos problèmes. J'ai lorgné du coté de symphony pour regarder
>comment ils faisaient, j'ai donc commencé une lib
>inc/admin/class.dc.form.php.
>
>Concrètement, cela ajoute des fonctions twig particulières de type form_field.
>
>Une entrée template rendu pour un formulaire de l'admin se résume alors à :
>{% form post %}
> <p>{{ form_field('cat_id')}}</p>
> <p>{{ form_field('post_status')}}</p>
> <p>{{ form_field('post_dt')}}</p>
> <p>{{ form_field('post_format')}}</p>
> <p>{{ form_field('post_open_comment')}}</p>
> <p>{{ form_field('post_open_tb')}}</p>
> <p>{{ form_field('post_selected')}}</p>
> <p>{{ form_field('post_lang')}}</p>
>{% endform %}
>
>Coté code php, on pousse les champs correspondants via le contexte
>qu'on transmet au template :
>$form = new dcForm($core,'post','post.php');
>$form
> ->addField(
> new dcFieldHidden('post_id',''))
> ->addField(
> new dcFieldText('post_title','', array(
> 'size' => 20,
> 'required' => true,
> 'label' => __('Title'))))
> ->addField(
> new dcFieldTextArea('post_excerpt','', array(
> 'cols' => 50,
> 'rows' => 5,
> 'label' => __("Excerpt:"))))
> ->addField(
> new dcFieldTextArea('post_content','', array(
> 'required' => true,
> 'label' => __("Content:"))))
> ->addField(
> new dcFieldTextArea('post_notes','', array(
> 'label' => __("Notes"))));
>
>
>Le rendu est fait de cette forme :
>
>$page = new dcAdminPage($core);
>$ctx = $page->getContext();
>$ctx
> ->jsDatePicker()
> ->jsToolBar()
> ->jsModal()
> ->jsMetaEditor()
> ->jsLoad('js/_post.js')
> ->jsPageTabs($default_tab)
> ->jsConfirmClose('entry-form','comment-form');
>
>echo $page->render('post.html.twig',array(
> 'edit_size'=> $core->auth->getOption('edit_size')));
>
>
>A force d'écrire, je me dis qu'il vaudrait mieux que je pushe le code
>quelque part. Je crée une branche à quel endroit ?
>
>Je devrais pouvoir faire quelque chose qui affiche des trucs
>rapidement, sachant qu'il restera du boulot :)
>
>--
>Bruno
>_______________________________________________
>Dev mailing list
>Dev(a)list.dotclear.org
>http://ml.dotclear.org/listinfo/dev
11 years, 5 months
Twig : le topo
by Dsls
Hello,
Ci-dessous mes avancements sur le sujet twig. A l'ordre du jour :
Concernant la lib : j'ai bossé sur la v1.6.3, il faudrait voir ce
qu'il faut adapter pour la v1.11.1 toute fraîche. Elle est positionnée
dans inc/lib/twig
Coté admin, Twig tout seul ne suffit pas/ne résoudra pas forcément
tous nos problèmes. J'ai lorgné du coté de symphony pour regarder
comment ils faisaient, j'ai donc commencé une lib
inc/admin/class.dc.form.php.
Concrètement, cela ajoute des fonctions twig particulières de type form_field.
Une entrée template rendu pour un formulaire de l'admin se résume alors à :
{% form post %}
<p>{{ form_field('cat_id')}}</p>
<p>{{ form_field('post_status')}}</p>
<p>{{ form_field('post_dt')}}</p>
<p>{{ form_field('post_format')}}</p>
<p>{{ form_field('post_open_comment')}}</p>
<p>{{ form_field('post_open_tb')}}</p>
<p>{{ form_field('post_selected')}}</p>
<p>{{ form_field('post_lang')}}</p>
{% endform %}
Coté code php, on pousse les champs correspondants via le contexte
qu'on transmet au template :
$form = new dcForm($core,'post','post.php');
$form
->addField(
new dcFieldHidden('post_id',''))
->addField(
new dcFieldText('post_title','', array(
'size' => 20,
'required' => true,
'label' => __('Title'))))
->addField(
new dcFieldTextArea('post_excerpt','', array(
'cols' => 50,
'rows' => 5,
'label' => __("Excerpt:"))))
->addField(
new dcFieldTextArea('post_content','', array(
'required' => true,
'label' => __("Content:"))))
->addField(
new dcFieldTextArea('post_notes','', array(
'label' => __("Notes"))));
Le rendu est fait de cette forme :
$page = new dcAdminPage($core);
$ctx = $page->getContext();
$ctx
->jsDatePicker()
->jsToolBar()
->jsModal()
->jsMetaEditor()
->jsLoad('js/_post.js')
->jsPageTabs($default_tab)
->jsConfirmClose('entry-form','comment-form');
echo $page->render('post.html.twig',array(
'edit_size'=> $core->auth->getOption('edit_size')));
A force d'écrire, je me dis qu'il vaudrait mieux que je pushe le code
quelque part. Je crée une branche à quel endroit ?
Je devrais pouvoir faire quelque chose qui affiche des trucs
rapidement, sachant qu'il restera du boulot :)
--
Bruno
11 years, 5 months
Re: [Dotclear Dev] Twig
by Jean-Christian Denis
OK merci ça va sûrement m'inspirer, mais je promet rien.
Dsls <dsls(a)morefnu.org> a écrit :
>> Bonjour tout le monde,
>
>Hello,
>
>> J'avais 5 minutes cette semaine alors j'ai jeté un coup d’œil au moteur
>> de template Twig. Je me suis amusé à mettre en template la page de login
>> de Dotclear pour me faire une idée et du coup plusieurs question me
>> viennent.
>> - Les deux formes d'écriture actuelle vs Twig ne sont pas compatibles
>> donc je pensais laisser le choix aux gens d'utiliser l'une ou l'autre
>> (et pour une transition plus douce) et ajouter une options aux
>> paramètres du define des thèmes qui indiquerait le moteur à utiliser.
>> Est-ce une bonne idée ?
>
>> - Est-ce mieux de traduire par exemple tous les filtres du moteur
>> actuelle (ex: encode_html) ou utiliser ceux de Twig (ex: e('html') ) ?
>
>J'ai fait une moulinette il y a un certain temps (1 an) qui convertit
>un thème dotclear en thème twig. Dans le principe, 2 tags twig sont
>créés, et les tpl:value sont remplacés par ces tags. Ca marchait
>plutôt pas mal... je retrouve mon mail et je le pousse sur la liste
>
>> Si on traduit tous on perd de l’intérêt à utiliser un nouveau moteur...
>> - J'ai très envie de passer la partie admin en template mais va falloir
>> externaliser tous les codes ainsi que servir les fichiers CSS, voir JS,
>> dois-je le faire en URL réel ou par une fonction style
>> "admin/index.php?pf=" ? Je suis pas super fort en sécu alors je ne sais
>> pas trop...
>> - Si je fais un moteur coté admin, ou est-ce que je met les thèmes admin?!
>Dans admin/default-templates :)
>
>> Bref ce sont quelques réflexions comme ça sur le coup, je ne sais pas si
>> j'aurais le temps d'avancer bcp plus loin, surtout que c'est pas trop ma
>> tasse de thé mais comme j'ai envie d'apprendre, autant en faire profiter
>> Dotclear ;-)
>
>Je peux te passer le boulot que j'avais commencé sur le sujet : en
>plus de twig coté admin, j'avais commencé à faire un framework de
>gestion de formulaires... laisse moi juste le temps de récupérer
>toutes mes billes et je package ça... (début de semaine, c'est sur mon
>pc pro)
>
>--
>Bruno
>_______________________________________________
>Dev mailing list
>Dev(a)list.dotclear.org
>http://ml.dotclear.org/listinfo/dev
11 years, 5 months
Re: [Dotclear Dev] 2.5-dev
by Jean-Christian Denis
Tiens, je l'ai relu cette après-midi même ! N'empêche que je ne m'y fait toujours pas et que je perd un temps fou avec... m'enfin ça viendra peut-être avec la pratique...
Franck Paul <carnet.franck.paul(a)gmail.com> a écrit :
>_______________________________________________
>Dev mailing list
>Dev(a)list.dotclear.org
>http://ml.dotclear.org/listinfo/dev
11 years, 5 months
(HS)
by Kozlika
Hey les admins de la liste : il n'y a pas moyen d'enlever automatiquement
la signature quand on est sur un "reply" ? Dans les longues discussions ça
fait des empilements longs comme le bras.
11 years, 5 months
2.5-dev
by Franck Paul
Bonjour m'sieur-dame,
Je crois avoir fait un peu le tour des tickets que je pouvais fermer et
j'aimerais que cette version 2.5-dev soit pas mal testée par ceux d'entre
vous qui pourront le faire (je sais que certains la testent déjà).
Les dernières nightlies sont ici :
http://download.dotclear.org/nightly/unstable/
Je rappelle que pour automatiser la mise à jour des versions de
développement il suffit de modifier le config.php de son installation pour
ajouter (ou modifier) ceci :
// Update info URL
define('DC_UPDATE_URL','http://download.dotclear.org/versions.xml'<http://download.dotclear.org/stage/versions.xml%27>
);
// Update info version
define('DC_UPDATE_VERSION','unstable');
Pendant ce temps je vais voir ce que je peux exploiter de la branche
form-filters, le plus gros étant déjà opérationnel, pour l'intégrer ensuite
dans la branche de développement. À ce sujet, si vous avez des retours sur
cette branche, faites-le moi savoir.
N'hésitez pas à :
- tester sur des environnements différents avec des navigateurs différents
- ouvrir des tickets, même s'ils vous paraissent bénins, ça sert
d'aide-mémoire, que ce soit pour des bugs, des améliorations, des idées,
etc etc…
- proposer des pull-requests sur le dépôts Dotclear chez Bitbucket (
https://bitbucket.org/dotclear/dotclear)
Bonne journée les gens
--
Franck
11 years, 5 months
Fwd: [Chantier-ergo] De retour avec un moteur de templates
by Dsls
---------- Message transféré ----------
De : Dsls <dsls(a)morefnu.org>
Date : 12 novembre 2010 15:04
Objet : Re: [Chantier-ergo] De retour avec un moteur de templates
À : chantier-ergo(a)list.dotclear.net
Le 12 novembre 2010 14:24, nikrou77(a)gmail.com <nikrou77(a)gmail.com> a écrit :
> Et pour aider à trancher, est-ce que ce serait une bonne idée de faire un
> POC avec Twig ? Evidemment il ne faut pas y passer 2 semaines !
> Qu'en pensez-vous ?
Si ça peut aider, j'avais expérimenté un urlhandler basé sur twig en
mars, avec une moulinette à thèmes pour une phase transitoire, le tout
sous la forme d'un plugin, d'un thème de démo (blowup adapté en twig)
et de quelques retouches du core.
En gros :
<tpl:Balise attr1="val1" attr2="val2"> ...</tpl:Balise> devient {% dcb
Balise attr1:"val1" attr2:"val2 %} ... {% eddcb %}
{{tpl:Balise attr1="val1" attr2="val2"}} devient {% dcv Balise
attr1:"val1" attr2:"val2 %}
Ca avait été fait à l'arrache, mais fonctionne. Je suis sûr qu'en
creusant un peu on peut même garder la syntaxe actuelle des thèmes et
la faire prendre telle quelle par Twig.
Pour ceusses qui veulent tester :
* Le plugin twig:
http://www.morefnu.org/public/archives/dotclear2/contrib/Twig/plugin-twig...
* Le thème twig:http://www.morefnu.org/public/archives/dotclear2/contrib/Twig/theme-...
Les modifs à faire dans le core (il y en a 2) sont dans le README.txt du plugin
Ze klingon iz back :)
--
Bruno
11 years, 5 months
Fwd: Twig coté thèmes, premières idées...
by Dsls
Quelques sujets sur twig que je pousse à nouveau...
---------- Message transféré ----------
De : Dsls <dsls(a)morefnu.org>
Date : 2 février 2011 16:13
Objet : Twig coté thèmes, premières idées...
À : Dotclear Bazar <bazar(a)list.dotclear.net>
Hello,
Un petit mail pour résumer ce que pourrait être un thème, version twig.
* Les bases
Les templates actuels sont basés sur 2 concepts : les blocs
<tpl:Block>...</tpl:Block> et les valeurs {{tpl:Value}}.
Ces concepts ont fait leurs preuves, cependant, dès qu'on veut sortir
un peu des sentiers battus, on passe souvent par la case plugin dès
lors qu'un tag n'affiche pas exactement ce qu'on souhaite. La cause
principale : les balises affichent quelque chose, et ne __retournent__
pas quelque chose qu'on pourrait exploiter/triturer.
L'idée de Twig est de remettre les choses à plat, de manière un peu
plus klingonne (mais pas trop quand même).
Twig définit des nouvelles balises :
* Les instructions simples {% instruction ... suites %}
* Les instructions de type bloc (ex : {% for p in posts %} ... {% endfor %})
* Les affichages de valeurs (équivalent aux values précédentes) : {{valeur}}
S'ajoutent à cela : des mots-clés évolués (boucles for, tests,
définition de variables), des filtres et des objets.
La présentation sur le site est assez complète et montre bien les
possibilités : http://www.twig-project.org/doc/templates.html
* Les impacts
Impact majeur : plus besoin de balises, il suffit d'"exposer" un objet.
Exemple :
Ancien template :
<tpl:Entries selected="1">
Titre : {{tpl:EntryTitle}}
</tpl:Entries>
Avec Twig :
{% set posts = blog.getPosts({'selected': '1'}) %}
{% for p in posts %}
Titre : {{p.post_title}}
{% endfor %}
Autre impact : il va falloir définir des classes blog "publiques", ou
un genre de "proxy" vers les classes actuelles pour limiter les appels
depuis les templates vers les classes du core.
Pour les filtres, on ne sera plus limité à encode_html ou cut_string
Filtrer un contenu aux 300 premiers caractères en enlevant les tags
html devient alors {{p.post_title|striptags|truncate(300)}}
Dernier point de ce mail : les blocs : on peut définir des blocs
fonctionnels, comme mentionné dans mes mails sur la refonte des
thèmes, et c'est supporté en natif. Idem pour l'héritage de templates
--
Bruno
11 years, 5 months
