personnellement, je prefère la syntaxe proposée par certains moteurs de template, tout simplement parce que :
1) ça facilite l'écriture et la lisibilité du template. pour faire un echo, pas besoin de faire des <?php echo $truc;?> de partout (et il y en a beaucoup dans un template des echo !), un simple {$truc} suffit dans smarty par ex. la syntaxe du template peut aussi inclure des fonctionnalités que ne fournit pas php. Exemple, dans jTpl ( http://www.jelix.org/articles/manuel/templates ), {@truc@} permet de récupérer et afficher une chaine localisée (dont la clé est truc). Pas besoin de faire à chaque fois un <?php echo getlocale('truc');?> ou autre..
Et je ne parle pas des facilités de formatages que peut apporter un moteur de template.
2) ça limite les tentations d'y faire des traitements métiers (surtout dans le cadre d'un framework). La syntaxe limitée (en théorie) des templates ne permet de faire que de l'affichage/formatage, et rien d'autre. Ce qui est le but recherché
3) le moteur peut aussi avoir une fonctionnalité de cache pour le contenu généré, ce qui peut être interressant.
4) Pour les arguments sur la contre-performance des moteurs de templates, ce n'est pas forcément valable quand le moteur transforme le template utilisé en fichier PHP et le met en cache (comme le font smarty ou jtpl par ex). Les différences de perf sont alors minimes (puisqu'alors le moteur se contente de faire un include PHP du cache)
5) La possibilité pour l'application d'accepter des templates "exterieurs" (uploadés par les utilisateurs par exemple, pour personnaliser un blog sur un site d'hebergement de blog par exemple, ou de personnaliser le rendu d'un document généré par l'appli) : comme le langage du template est limité et en theorie moins complexe pour php, il y a beaucoup moins de risque au niveau sécu pour l'appli, et c'est plus facile pour l'utilisateur.
Bon aprés, l'interet que l'on voit dans un moteur de template, c'est une histoire de goût, et surtout selon les besoins pour le développement de l'appli.
Note à propos de CSS : on ne fait pas tout avec CSS, surtout avec les implementations aléatoires dans les navigateurs. Il faut attendre au moins CSS3 pour dire que CSS est suffisement souple pour pouvoir styler comme on veut n'importe quel document XML/XHTML (et encore..). Quand on veut changer de "layout", d'organisation des éléments dans une page, il arrive qu'il faille modifier le html. Et si en plus l'auteur n'a pas mis suffisement de section (div), d'ID ou de class, ça devient complexe.. Bref, les templates (PHP ou autre) gardent leur interet.
[^] # Re: Quel intérêt ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de TPLN Template Processor 2.7. Évalué à 2.
1) ça facilite l'écriture et la lisibilité du template. pour faire un echo, pas besoin de faire des <?php echo $truc;?> de partout (et il y en a beaucoup dans un template des echo !), un simple {$truc} suffit dans smarty par ex. la syntaxe du template peut aussi inclure des fonctionnalités que ne fournit pas php. Exemple, dans jTpl ( http://www.jelix.org/articles/manuel/templates ), {@truc@} permet de récupérer et afficher une chaine localisée (dont la clé est truc). Pas besoin de faire à chaque fois un <?php echo getlocale('truc');?> ou autre..
Et je ne parle pas des facilités de formatages que peut apporter un moteur de template.
2) ça limite les tentations d'y faire des traitements métiers (surtout dans le cadre d'un framework). La syntaxe limitée (en théorie) des templates ne permet de faire que de l'affichage/formatage, et rien d'autre. Ce qui est le but recherché
3) le moteur peut aussi avoir une fonctionnalité de cache pour le contenu généré, ce qui peut être interressant.
4) Pour les arguments sur la contre-performance des moteurs de templates, ce n'est pas forcément valable quand le moteur transforme le template utilisé en fichier PHP et le met en cache (comme le font smarty ou jtpl par ex). Les différences de perf sont alors minimes (puisqu'alors le moteur se contente de faire un include PHP du cache)
5) La possibilité pour l'application d'accepter des templates "exterieurs" (uploadés par les utilisateurs par exemple, pour personnaliser un blog sur un site d'hebergement de blog par exemple, ou de personnaliser le rendu d'un document généré par l'appli) : comme le langage du template est limité et en theorie moins complexe pour php, il y a beaucoup moins de risque au niveau sécu pour l'appli, et c'est plus facile pour l'utilisateur.
Bon aprés, l'interet que l'on voit dans un moteur de template, c'est une histoire de goût, et surtout selon les besoins pour le développement de l'appli.
Note à propos de CSS : on ne fait pas tout avec CSS, surtout avec les implementations aléatoires dans les navigateurs. Il faut attendre au moins CSS3 pour dire que CSS est suffisement souple pour pouvoir styler comme on veut n'importe quel document XML/XHTML (et encore..). Quand on veut changer de "layout", d'organisation des éléments dans une page, il arrive qu'il faille modifier le html. Et si en plus l'auteur n'a pas mis suffisement de section (div), d'ID ou de class, ça devient complexe.. Bref, les templates (PHP ou autre) gardent leur interet.