Salut,
Je planche actuellement sur un projet de moteur de templates, et j’avoue qu’après avoir jeté un oeil sur Smarty (dont je voulais me servir de base), je suis un peu… perdu.
Voila, alors je voulais demander : selon vous, c’est quoi un moteur de templates ? Quelles fonctions doivent être implantées ?
Au début, je pensais faire un truc tout con qui remplace les {$Variable} par leur valeur, un système pour faire des blocs qui se répètent avec un tableau de données, etc. Mais après avoir vu Smarty… je ne sais plus trop si je me plante pas complètement la (bien que je crois que Smarty est couplé avec un parser).
en toute simplicité, un moteur de template est effectivement une boucle de str_replace() bien reflechie.
Mais avant de te lancer dedans, il te faut un cahier des charges precis, quel est le tien?
J’ai beau retourner le problème dans tous les sens… et j’en ai utilisé pas mal (genre smarty)… mais je vois toujours pas l’utilité ultime d’un moteur de template ?!
Moi pour designer les site je me sers de mon petit DreamWeaver (xhtml + CSS) qui me permet de cloisonner tout super proprement (php ou autre et interface) et surtout de bosser en WYSIWYG ! Y’a rien de plus agréable…
L’énorme avantage des moteurs de template, est normalement une séparation réelle du code et de l’affichage. Quand tu bosses en groupe, les grapheux peuvent pondre des interfaces sans se soucier du code, et les codeurs peuvent bosser sans se soucier de l’interface (enfin, en gros).
En plus, ça facilite la mise à jour, étant donné que les éléments de l’application sont clairement séparées. En fait, c’est plus un modèle n-tiers qu’autre chose.
Tu parles de Xhtml + CSS, ça n’a clairement rien à voir avec un moteur de template hein. Ca ne fait que décrire la manière dont doivent s’afficher tes éléments html, mais tu dois quand même dans le php faire toi même les boucles pour générer tes tableaux, ou autre replace des familles. Le moteur de template est censé bannir plus ou moins toute présence d’html de ta couche métier.
Bon j’ai toujours été une quiche en explications, donc j’espère que ce sera assez clair
Personnellement je n’ai jamais saisi l’intérêt des moteurs de template, puisque pour moi PHP remplit nativement cette fonction, même en gardant une séparation métier/présentation. Mes balises de “templates” sont des <?php echo $variable ?> que je ne suppose pas plus obscures pour un graphiste pur et dur que <[variable]> ou je sais pas quoi :P. Le seul défaut que je concède c’est que la syntaxe n’est pas “compatible” XML donc dans un éditeur wysiwyg c’est pas tip top.
Enfin bon si les moteurs de template ont tant de succès, c’est qu’il y a forcément quelque chose que je vois pas dedans, puisque même l’auteur de dotclear (olivier meunier) qui était contre les moteurs de template va en utiliser un pour dotclear 2.0.
Pour le moment le seul que j’ai réussi à accepter et utiliser est celui de textpattern, que je trouve fort pratique et fort élégant.
Bon alors il faut imaginer la factorisation de code. Entre écrire n fois des boucles pour générer des tableaux en html, et avoir un simple objet à qui on passe les données, et qui se débrouillent tout seul pour générer, je préfére la deuxième solution. Surtout si ce même objet se débrouille également pour pondre de l’html compatible avec tous les navigateurs. On peut rajouter également l’option de mise en cache, histoire que la page ne se regénére qu’en cas de modif dans la base, et on obtient une application avec une séparation claire des couches, optimisé, et dont le code est bien factorisé, et du coup plus facile à relire.
J’aimerais préciser un détail dans ce que BodySplash écrit et qui fait bien comprendre l’intérêt quand il dit que les grapheux s’en foutent du code c’est que puisque le moteur de template est un “language” dans le “language” il est IMPOSSIBLE qu’ils pêtent le code en oubliant de fermer une balise ‘?>’, ou qu’ils provoquent des erreurs ‘PHP’ à l’affichage (you don’t want your user to see this) en faisant des boucles ou des conditions foireuses. Le moteur de template attrape tout.
Donc ok c’est une couche en plus. Mais on pourrait prendre le même template et l’utiliser dans un site asp, .net, perl, whatever parce que le moteur de template derrière fait que c’est complètement séparé (avec du code ‘<? echo’ ou ‘while {}’ on est tout de suite esclave de la syntaxe, de la configuration du serveur, etc… Le template est permutable.
(fin c’est un des gros avantage que je vois, maintenant se cogner l’écriture du moteur de template : p beurk)
Moi ca me dérange pas de retrouver des éléments HTML simples dans du code PHP : ,
,
, <hn>,etc…
Du moment que tout ce qui est généré par ce PHP est une page XHTML prête à être skinnée en CSS… là où ce serait lourdingue c’est de retrouver la mise en page dans le PHP ! Là je suis d’accord !
[quote=« nolan, post:8, topic: 27421 »]Donc ok c’est une couche en plus. Mais on pourrait prendre le même template et l’utiliser dans un site asp, .net, perl, whatever parce que le moteur de template derrière fait que c’est complètement séparé (avec du code ‹ <? echo › ou ‹ while {} › on est tout de suite esclave de la syntaxe, de la configuration du serveur, etc… Le template est permutable.
(fin c’est un des gros avantage que je vois, maintenant se cogner l’écriture du moteur de template : p beurk)[/quote]
Ah là ok. C’est un avantage auquel je n’avais jamais songé, codant bien souvent qu’en Php. Je suppose que les cas de ce genre de besoins doivent rester rares, non? D’ailleurs, existe-t-il un moteur de template qui soit « multi langage serveur »?
[quote=« jarod, post:9, topic: 27421 »]Moi ca me dérange pas de retrouver des éléments HTML simples dans du code PHP : ,
, , <hn>,etc…
Du moment que tout ce qui est généré par ce PHP est une page XHTML prête à être skinnée en CSS… là où ce serait lourdingue c’est de retrouver la mise en page dans le PHP ! Là je suis d’accord ![/quote]
La je suis d’accord avec Gregouze, c’est pas beau comme approche En plus tu te contredis, parce que pour moi, les ,
et autres
, c’est de la présentation. Ca veut dire que quand tu veux faire une modif dans la manière de présenter les données, tu dois chercher partout dans ton code, alors qu’avec un moteur, ça se passe à un seul endroit et la messe est dite.
Enfin bref, j’ai donc commencé l’écriture proprement dire du moteur, et en effet, je rejoint nolan : beurk. Mais c’est que j’essaie de faire tout plein de projets de sites, et comme je voudrais utiliser les templates pour les faire, je me suis dit que d’abord il fallait faire un moteur
Enfin bref, j’ai donc terminé le parsage simple des {$Variable} et autre {$Variable.ID}, mais maintenant je planche sur un beau truc qui pourrais par exemple chopper des données MySQL, et dupliquer une partie de la template autant de fois de nécéssaire.
Exemple :
{BLOC News}
{$News.Titre}
{$News.Texte}{/BLOC}
Seul problème : mon moteur doit donc aller dans MySQL pour chopper les données, et la c’est le drame : j’adore utiliser MySQLi, mais je ne peux pas l’imposer à mes utilisateurs, alors soit je :
Abandonne cette balise.
Crée un système étendu qui prend en charge les templates et MySQL.
Ton moteur de template n’a clairement pas à aller chercher les données lui-même, ce n’est pas son métier. Lui il est juste censé afficher les infos, et le faire bien
Pour ce que tu veux faire, c’est à ta couche métier de récupérer les données, de les mettre dans un beau tableau, et ton moteur de template se charge de boucler sur chaque ligne pour générer la présentation que tu veux.
Et à ton avis, dois-je inclure un support pour parser les données (du style effacer les tags HTML, etc.) ? Enfin je veux dire cela rentre-il dans le cadre de l’affichage ? Ou plutôt de la sécurité ?
Si j’ai bien compris, tu veux « nettoyer » les données? Là je dois dire que je me tate un peu, mais j’aurai tendance à penser que c’est au moment de la saisie des infos qu’il faut vérifier leur intégrité, mais tu peux toujours inclure un parser dans ton moteur pour faire gaffe aux caractères spéciaux (genre, remplacer les < et > par des < et >), ça ne me paraît pas illogique.
Je rejoins Body en ayant pas d’avis précis. Personellement je m’assure de la sécurité des données d’un point de vue SQL lors de la réception des données, et je passe par un htmlentities() avant de les afficher. Mais je reste ouvert
[quote=« Metzgermeister, post:17, topic: 27421 »]Et quant aux systèmes du style mise en forme de la date, etc. c’est aussi une bonne idée ou non ?
Edit : C’est pas grave, on a le temps ;p[/quote]
Aaah le système de date je trouve que c’est ce qu’il y a de plus contraignant dans les CMS, puisque bien souvent il faut aller tripatouiller dans l’interface d’admin pour entrer un format compréhensible par PHP. Tu auras compris que je préfère refiler toutes les variables de date au template et qu’il se débrouille avec. Ce qui permet d’avoir plusieur templates avec un affichage de date différent. Certes, c’est plus long à écrire dans le template, mais bon
D’ou l’interêt du moteur automatisé
Enfin bref, j’ai aussi trouvé que Smarty était pas mal rempli de trucs pas forcément utiles : exemple des structures de contrôles IF, des balises pour insérer du code PHP (WTF ?), etc.
Je comptais aussi créer une fonction pour mettre les dates en français
Je rejoins ton avis : je préfère définir l’éventuel traitement des données (comme par exemple une date correcte :P).
[quote=« Metzgermeister, post:19, topic: 27421 »]D’ou l’interêt du moteur automatisé
Enfin bref, j’ai aussi trouvé que Smarty était pas mal rempli de trucs pas forcément utiles : exemple des structures de contrôles IF, des balises pour insérer du code PHP (WTF ?), etc.[/quote]
Ca, ça peut etre utile pour de la mise en forme conditionnelle.
Imaginons que tu veuilles alterner les couleurs dans ton tableau, genre une ligne telle couleur, et la suivante de l’autre. Tu peux le faire en testant le numéro de ligne, et assigner un style en fonction.
Bref, il y a tout un paquet de données qui peuvent influer sur ton affichage, et c’est le bon endroit pour le faire. Ensuite, pouvoir insérer du code php, je suis un peu moins d’accord.
