Pour compléter à propos de jTpl (dont je suis l'auteur :-), j'ai essayé d'avoir les avantages à la fois des templates pur php, et d'un langage de template spécifique, à savoir :
* faciliter l'écriture. par exemple, remplacer les "<?php echo $variable?>" par une syntaxe plus simple comme {$variable}
* sans toutefois ne pas avoir à reinventer totalement un langage, c'est pourquoi les expressions utilisées sont en php. ex: {$variable.$objet->propriete} qui est équivalent à...<?php echo $variable.$objet->propriete?> tout simplement :-)
* mais en posant des restrictions, pour éviter d'avoir du code métier dans les templates, c'est pourquoi les expressions sont parsées (en utilisant le tokenizer de php ;-) et "filtrées".
il y a des tags typiques comme {foreach}, {for}, {if} et cie, fonctionnant comme en php.
Alors, ubitux trouve que c'est une abération que d'avoir des if/while dans un template, à ceci je lui repondrais :
1) il est lui même en contradiction avec ce qu'il dit, puisqu'il semble être pour utiliser PHP pour les templates, et donc ces templates peuvent contenir des if/while...
2) il y a des moteurs de templates qui obligent à faire les boucles en dehors du template, c'est à dire que dans le template lui même, on définit les "blocs" qui seront itérés, et en dehors du template, en php, on fait les boucles, et on appele des méthodes du moteur de template pour générer les blocs à chaque itération. Je trouve cela complètement ridicule, car dès lors que l'on veuille faire des modifications dans le template, il faut alors modifier en même temps le template ET le code php externe au template. Ce qui limite grandement les modifications, donc la personnalisation des templates
ex, dans le template original, on affiche une liste dans une seule colonne, donc une boucle, et dans notre nouveau theme, on veux que ce soit sur deux colonnes, donc deux boucles, ou alors une seule mais faudrait pouvoir ajouter un test à l'interieur pour savoir si on est arrivé au milieu de la liste pour créer la deuxieme colonne etc..
Avec ce genre de moteur de template, on est donc obligé de modifier le code PHP externe, donc le code de l'appli. Et puis cela veut dire aussi que la couche "vue" est scindée en deux "sous-couche", la logique de construction d'un coté (qui n'empèche pas de mélanger allègrement avec du code métier, ce qui est dommage), le code purement html de l'autre, ce qui n'est vraiment pas terrible, du point de vue de la maintenance et l'évolution.
Je préfère donc de loin, les moteurs de templates qui autorisent les instructions de contrôles if/foreach et cie.
Enfin, avoir une syntaxe un peu spécifique et controllée comme celle de jtpl permet d'une part, de faciliter l'écriture des templates par des webdesigners, mais aussi de permettre à l'application par exemple de proposer à un utilisateur d'uploader un template ou un thème sans compromettre la sécurité de l'application (jTpl a d'ailleurs un mode de fonctionnement avancé pour ce genre de template, apportant encore plus de sécurité)
J'oubliais aussi: comme Smarty, jTpl génère des fichiers PHP à partir des templates et les mets en cache, ce qui évite le parsing du template à chaque utilisation. Donc point de vue performance, la différence est vraiment insignifiante par rapport à un template pure php (il y a en gros un file_exists pour vérifier l'existance du cache, et un simple include du cache).
Autre avantage de jTpl par rapport à smarty : 320 lignes de codes pour le moteur + 520 pour le "compilateur" (non chargée si le cache est ok), commentaires compris, contre plus de 1900+2800 pour smarty ... Les caches d'opcodes apprecieront... (pour un nombre de fonctionnalité à peu près équivalent, quelques features bloatware en moins dans jtpl)
[^] # Re: Un moteur de templates est très utile
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 2.
* faciliter l'écriture. par exemple, remplacer les "<?php echo $variable?>" par une syntaxe plus simple comme {$variable}
* sans toutefois ne pas avoir à reinventer totalement un langage, c'est pourquoi les expressions utilisées sont en php. ex: {$variable.$objet->propriete} qui est équivalent à...<?php echo $variable.$objet->propriete?> tout simplement :-)
* mais en posant des restrictions, pour éviter d'avoir du code métier dans les templates, c'est pourquoi les expressions sont parsées (en utilisant le tokenizer de php ;-) et "filtrées".
il y a des tags typiques comme {foreach}, {for}, {if} et cie, fonctionnant comme en php.
Alors, ubitux trouve que c'est une abération que d'avoir des if/while dans un template, à ceci je lui repondrais :
1) il est lui même en contradiction avec ce qu'il dit, puisqu'il semble être pour utiliser PHP pour les templates, et donc ces templates peuvent contenir des if/while...
2) il y a des moteurs de templates qui obligent à faire les boucles en dehors du template, c'est à dire que dans le template lui même, on définit les "blocs" qui seront itérés, et en dehors du template, en php, on fait les boucles, et on appele des méthodes du moteur de template pour générer les blocs à chaque itération. Je trouve cela complètement ridicule, car dès lors que l'on veuille faire des modifications dans le template, il faut alors modifier en même temps le template ET le code php externe au template. Ce qui limite grandement les modifications, donc la personnalisation des templates
ex, dans le template original, on affiche une liste dans une seule colonne, donc une boucle, et dans notre nouveau theme, on veux que ce soit sur deux colonnes, donc deux boucles, ou alors une seule mais faudrait pouvoir ajouter un test à l'interieur pour savoir si on est arrivé au milieu de la liste pour créer la deuxieme colonne etc..
Avec ce genre de moteur de template, on est donc obligé de modifier le code PHP externe, donc le code de l'appli. Et puis cela veut dire aussi que la couche "vue" est scindée en deux "sous-couche", la logique de construction d'un coté (qui n'empèche pas de mélanger allègrement avec du code métier, ce qui est dommage), le code purement html de l'autre, ce qui n'est vraiment pas terrible, du point de vue de la maintenance et l'évolution.
Je préfère donc de loin, les moteurs de templates qui autorisent les instructions de contrôles if/foreach et cie.
Enfin, avoir une syntaxe un peu spécifique et controllée comme celle de jtpl permet d'une part, de faciliter l'écriture des templates par des webdesigners, mais aussi de permettre à l'application par exemple de proposer à un utilisateur d'uploader un template ou un thème sans compromettre la sécurité de l'application (jTpl a d'ailleurs un mode de fonctionnement avancé pour ce genre de template, apportant encore plus de sécurité)
J'oubliais aussi: comme Smarty, jTpl génère des fichiers PHP à partir des templates et les mets en cache, ce qui évite le parsing du template à chaque utilisation. Donc point de vue performance, la différence est vraiment insignifiante par rapport à un template pure php (il y a en gros un file_exists pour vérifier l'existance du cache, et un simple include du cache).
Autre avantage de jTpl par rapport à smarty : 320 lignes de codes pour le moteur + 520 pour le "compilateur" (non chargée si le cache est ok), commentaires compris, contre plus de 1900+2800 pour smarty ... Les caches d'opcodes apprecieront... (pour un nombre de fonctionnalité à peu près équivalent, quelques features bloatware en moins dans jtpl)
http://jelix.org/articles/fr/manuel-1.1/templates
Teasing: la version 1.0 de jTpl standalone sort très bientôt