Dotclear

Vous n'êtes pas identifié(e).

Annonce

13 février 2024 Sortie de Dotclear 2.29

#1 2013-07-14 12:11:42

Dsls
Modérateur couteau-suisse
Inscription : 2004-11-18
Site Web

[dev][Branche twig] Description de la branche

Hello,

Histoire de poser les bases des réflexions en cours, et en parallèle des divers échanges sur le forum, je pose ici le but de la branche twig qui a été créée il y a quelques temps, et dont le but est d'être réintégrée à la branche sexy. Cette branche est visible sur le référentiel officiel, et navigable ici : http://dev.dotclear.org/2.0/browser/?re … 7267aec27b

Constat / état des lieux à ce jour
* Coté partie publique, un moteur de templates spécifiques est fourni par clearbricks
* Coté admin, tout est fait à la mimine par les pages d'admin elles-mêmes. Le corps des pages est fourni par la classe dcPage (dans inc/admin/lib.dc.page.php)

But de cette branche
* Introduire le moteur Twig de manière progressive en remplacement des briques clearbricks
* Dans un premier temps, la partie admin basculera vers Twig et la partie publique restera avec le moteur de templates actuel
* Quand ce sera rôdé coté admin, une transition de la partie publique et des thèmes sera faite vers Twig, avec une moulinette de compatibilité avec l'ancien balisage
* Pour l'occasion, toute la partie liée à l'ancien moteur sera migrée vers un plugin "dcLegacy", lequel disparaîtra à long terme.

Ce qui a été fait à ce jour
Pour l'instant JC et moi avons commencé à poser les bases : les pages index.php, post.php, posts.php, auth.php ont commencé à migrer vers des templates twig, définis dans le répertoire inc/admin/default-templates.

De mon côté, n'ayant pas trouvé d'équivalent, j'ai commencé à travailler sur un framework de gestion de formulaires : dcForm (class.dc.form.php, qui se présente comme une extension à twig), qui permet de définir simplement des champs de formulaires, et de les faire afficher dans un template twig. Les champs de formulaire sont définis dans un template fortement inspiré de ce que fait Symfony, dans inc/admin/default-templates/forms/form_layout.html.twig.
Ce qui permet dans post.php d'avoir quelque chose du genre :

$form = new dcForm($core,'post','post.php');
$form
	->addField(
		new dcFieldText('post_title','', array(
			'size'		=> 20,
			'required'	=> true,
			'label'		=> __('Title'))));
//[...]

$form->setup();

$core->tpl->display('post.html.twig');

et dans post.html.twig (en élagant bien le code autour):

{% extends "layout.html.twig" %}
{% block content %}
{{ parent() }}
{% form 'post' %}
<div id="entry-wrapper">
	<div id="entry-content">
		<div class="constrained">
			<p class="col">{{ form_field('post_title',{'class':'maximal'}) }}</p>
		</div>
	</div>
</div>
{% endform %}
{% endblock %}

Autres contraintes : pouvoir gérer des listes d'éléments, avec des sélections/actions possibles, ainsi que la définition de filtres sur les entrées, suffisamment génériques : les classes dcFilter et dcList.

Un peu plus complexes qu eles précédentes, la gestion des actions des listes n'est pas encore opérationnelle, il reste à voir comment articuler le tout, avec notamment :
* Permettre aux plugins d'ajouter leurs actions
* Permettre des pages intermédiaires pour les actions (ex : "changer la catégorie" aboutit à une page intermédiaire permettant de sélectionner la catégorie souhaitée).

Beaucoup de code est encore tout frais et ne demande qu'à évoluer :)


Dyslexics have more fnu!

Hors ligne

#2 2013-07-14 13:25:30

tbex
Membre
Inscription : 2012-03-04

Re : [dev][Branche twig] Description de la branche

Bonjour,

Je me demandais juste, quelles sont les raisons qui vous poussent aujourd'hui, à terme, à remplacer l'ancien système de templates, par Twig, qui si je comprends bien sera utilisé, à la fois, pour le backend et le frontend. Le système de templates actuel n'est-il plus à votre convenance (Clearbricks c'est ça ?) ? Si oui pour quel raison ?
Pourquoi votre choix s'est-il porté en particulier sur Twig pour prendre la relève ? Est-ce un effet de mode ? Ou bien y a t'il un réel argument côté technique et performance ? Avez vous réfléchi à d'autres systèmes de templates comme Smarty par exemple ?

Une fois la bascule vers Twig terminé, sera t'il nécessaire d'adapter nos templates et design de blog (je pense notamment aux différentes balises) ou bien est-ce que se sera transparent pour l'utilisateur final ?

C'est juste de la curiosité, j'essaye de comprendre, je ne porte aucun jugement sur vos choix techniques.

Cordialement,

Dernière modification par tbex (2013-07-14 13:36:35)

Hors ligne

#3 2013-07-14 14:04:17

Dsls
Modérateur couteau-suisse
Inscription : 2004-11-18
Site Web

Re : [dev][Branche twig] Description de la branche

tbex a écrit :

Je me demandais juste, quelles sont les raisons qui vous poussent aujourd'hui, à terme, à remplacer l'ancien système de templates, par Twig, qui si je comprends bien sera utilisé, à la fois, pour le backend et le frontend. Le système de templates actuel n'est-il plus à votre convenance (Clearbricks c'est ça ?) ? Si oui pour quel raison ?

Le moteur de templates actuel de dotclear a ses limites : il est plutôt rigide, pas facile à étendre, et assez peu tolérant quant aux arguments. Par ailleurs il a sa propre syntaxe (que je trouve lourde personnellement). De plus il a très (trop ?) peu évolué ces derniers temps, et plutôt que de le faire évoluer, on préfère déléguer cela à quelqu'un d'autre

Pourquoi votre choix s'est-il porté en particulier sur Twig pour prendre la relève ? Est-ce un effet de mode ? Ou bien y a t'il un réel argument côté technique et performance ? Avez vous réfléchi à d'autres systèmes de templates comme Smarty par exemple ?

Twig a une bonne réputation, en plus d'avoir une syntaxe assez familière pour beaucoup de monde (identique à jinja ou django). Pourquoi Twig plutôt que Smarty ? Pour avoir vu smarty, je trouve Twig bien mieux conçu au niveau du code et de l'OOP, et plus clair au niveau de l'API. Après c'est une question de goût :)

Une fois la bascule vers Twig terminé, sera t'il nécessaire d'adapter nos templates et design de blog (je pense notamment aux différentes balises) ou bien est-ce que se sera transparent pour l'utilisateur final ?

J'ai déjà dans mes protos (depuis 2 ans déjà) un moteur de templates coté public basé sur twig, complètement transparent vis-à-dis des templates dotclear actuels. Il s'agira d'un module "legacy" qui comprendra une moulinette de traduction intégrée.


Dyslexics have more fnu!

Hors ligne

#4 2013-07-14 15:23:32

tbex
Membre
Inscription : 2012-03-04

Re : [dev][Branche twig] Description de la branche

Merci beaucoup pour toutes ces précisions. Je tiens aussi à souligner ma satisfaction de savoir que je n'aurais pas à toucher à mes templates =). J'ai hâte de voir la concrétisation de tous ça ^^ !

Cordialement,

Hors ligne

#5 2013-07-18 04:33:18

sogox
Membre
Inscription : 2013-07-16

Re : [dev][Branche twig] Description de la branche

Bonjour,
Il est surprenant de devoir recoder un moteur de formulaire.
Pourquoi ne pas utiliser symfony2/form qui peut être utilisé en dehors d'un projet symfony2 (je ne dis pas que c'est simple) (et qui s’intègre directement à Twig) mais il a l'aventage de gérer facilement la validation et l'internationalisation)

Voir l'implémentation dans Silex
http://silex.sensiolabs.org/doc/providers/form.html

Hors ligne

#6 2013-07-18 07:14:41

Dsls
Modérateur couteau-suisse
Inscription : 2004-11-18
Site Web

Re : [dev][Branche twig] Description de la branche

J'ai testé à une époque symfony2/form, mais je me souviens avoir tiré pas mal de dépendances au final. Si quelqu'un parvient à me montrer une intégration propre de symfony2/forms, je suis partant pour recommencer le boulot de la branche twig avec cela.

Ce que j'ai eu du mal à trouver (de mémoire) dans symfony2/forms :
* la gestion des champs multi-entrées (avec les <input name="entries[]"> qui sortent un tableau)
* la séparation des contraintes liées au champ lui-même (ex: longueur du texte) et les contraintes d'affichage (ex : largeur du champ texte, classes css, ...)


Dyslexics have more fnu!

Hors ligne

Vous n'êtes pas identifié(e).

Pied de page des forums

Sites map