Moteurs de templates : fausse bonne idée ?

Par

Aujourd’hui, j’inaugure le « Guest blogging » avec un article vraiment très intéressant de Nicolas Torres (@noclat) sur l’intérêt mais aussi et surtout les « pièges » à éviter lorsqu’on utilise un moteur de templates (comme Smarty par exemple).

PHP se suffit à lui-même pour effectuer du templating, en déclarant toutes les variables dans un fichiers de traitement, et en les appelant dans un fichier d’affichage inclus à la fin du traitement. Pourquoi les développeurs utilisent-ils alors une surcouche ?

Mauvaises excuses

J’ai souvent entendu « pour que celui qui s’occupe de l’affichage n’aie pas besoin de connaissances en PHP » ou « pour appliquer simplement un cache par fichier « parsé » (inclus et interprété) ».

Effectivement la plupart de ces moteurs recréent une syntaxe simplifiée qui raccourcis le temps de codage et permettent une meilleur lisibilité du code telle que :

{variable}

au lieu de :

<?php echo $variable; ?>

La faiblesse d’un tel procédé

« Parser », c’est consommer. Pour pouvoir interpréter correctement la syntaxe il faut utiliser des procédés de réécriture qui pèsent au chargement. Heureusement, lorsque le script est bien conçu, on n’effectue cette réécriture (compilation) qu’une seule fois après chaque modification du fichier template. Cela dit pour celui sur qui ça tombe, un mauvais « parseur » peut entraîner un lourd ralentissement pour une simple page.

Les programmeurs aimant bien s’inventer leur propre syntaxe et l’optimiser pour leur utilisation, ils sont parfois trop gourmands et confèrent à celle-ci bien plus de portée qu’elle ne devrait en posséder.

En effet certains ont tendance à vouloir appliquer des fonctions (date(), htmlspecialchars_decode(), nl2br()) au moment de l’appel de la variable. Hors il s’agit de traitement, et le traitement des données doit s’effectuer avant l’affichage.

Plus la syntaxe est développée, moins elle a d’intérêt, puisque son seul but est de diminuer le temps de codage et de gagner en lisibilité. J’ai souvent vu des moteurs utiliser une syntaxe XML telle que :

<foreach nom="nom_du_bloc">
    <var nom="variable" />
</foreach>

qui possède un rapport performance/confort relativement faible par rapport à la syntaxe native :

<?php foreach ($nom_du_bloc as $row) : ?>
    <?php echo $row['variable']; ?>
<?php endforeach; ?>

A noter que la syntaxe PHP permet bien plus de souplesse dans la déclaration d’une boucle (concaténation, et « variable double » ($$variable) autorisées).

De plus, le cache peut être totalement indépendant. Il n’est donc pas nécessaire de passer par un moteur de templates pour pouvoir en appliquer un.

Les bonnes pratiques

On utilise un tel outil pour séparer le traitement de l’affichage, et optionnellement pour minimiser son code et le rendre plus clair.

Plusieurs approches sont alors pertinentes face à la question des performances. C’est certain, regrouper ses variables dans une « boîte noire », loin des variables servant uniquement au traitement, est dans une certaine mesure très agréable. Mais avant de se jeter sur un moteur de templates, rélféchissez à quelle quantité de performance vous êtes prêt à céder.

Un moteur sans syntaxe personnalisée

C’est la solution la moins onéreuse. Le fameux framework CodeIgniter y a établi son camp. Pour gagner en confort, il est conseillé de trouver une solution pour séparer ses variables d’affichage à celles de traitement. L’une d’entre elles est de stocker ses variables dans un objet et inclure le fichier template dans une méthode en utilisant la fonction extract().

Un moteur à syntaxe

Prudence. Assurez-vous d’avoir une syntaxe suffisamment légère, et peu de fonctionnalités. Un moteur mettant à disposition l’appel de fonctions dans sa syntaxe doit être scrupuleusement analysé avant d’être employé. Le minimum nécessaire ? Appel de variables, boucles (appel de blocs) et conditions. Vérifiez que preg_replace()preg_replace_callback() et preg_match_all() sont utilisées avec parcimonie car ils consomment des quantités astronomiques de performances.

Conclusion

Je ne me veux pas exhaustif sinon préventif quant à l’optimisation des performances. Avouez qu’écrire autant de code aussi complexe et moins souple que PHP pour perdre en performance est dénué de sens. Il est préconisé de chercher l’équilibre entre la performance et le confort, et enfin de garder en tête que le traitement n’est pas du ressort de l’affichage.

  • http://twitter.com/Tmbdrogba Thomas Mauduit-Blin

    Totalement d’accord avec toi. Seulement lorsque l’on utilise un moteur de template, c’est généralement pour de très gros projets. Pour ce genre de projet, que l’on utilise un moteur de template ou non, ça reste très gourmand niveau ressources.

    Alors à mon avis, autant taper un peu plus de ligne PHP pour avoir un code clair, lisible, et facilement modifiable, ce qui à l’arrivée sera toujours plus appréciable et mieux optimisé qu’un code « brouillon » où tout est mélangé, et qui atteindra forcément ses limites au fur et à mesure de l’évolution du projet.

  • http://blog.synapse-studio.fr Anthony

    C’est un article remplis de bon sens mais je ne suis pas d’accord avec le principe.

    En effet je travail à ~90% avec un moteur de template ( Smarty en l’occurrence ) et à chaque fois que je dois retomber sur un projet ayant une gestion de l’affichage dans le dur, j’ai de plus en plus de mal.

    Je trouve qu’un des premiers avantages dans l’utilisation d’un moteur de template est dans une certaine rigueur du code, il est vrais que cette notion est assez subjective, un système de template ne force pas a mieux coder mais il permet d’éviter certaines erreurs.

    Avec du PHP dans la vue, il peut être (trop) tentant d’y faire du traitement en plein milieu de l’affichage. Après, travaillant avec Smarty j’ai une approche spécifique du moteur de template, il est, à mes yeux, l’élément logique dans une conception MVC.

    Ensuite, je ne pense pas que l’argument de la facilité coté intégrateur soit faux, je le trouve parfaitement valide, je suis développeur et également intégrateur et je trouve largement plus clair un template utilisant un moteur de ce type.

    Après il est certain que c’est avant tout une question de préférence personnelle, c’est une manière de travailler qui ne plait pas forcement à tous le monde.

    En rédigeant ce commentaire, j’ai oublier de citer un projet qui montre bien, je trouve, les problèmes liès à la non utilisation d’un moteur de template. Il est question de WordPress, système de blog génial mais géstion de l’affichage chaotique, des fonctions sont en plein milieu de templates, c’est un joyeux bordel quand il faut intervenir sur un projet fait à l’arrache, soit la grande majorité des projets sur lesquels il faut intervenir.

  • http://ntorres.me Nicolas Torres

    @twitter-101860984:disqus @anthony_synapse:disqus Je vous réponds simultanément car vos idées se rejoignent. Je ne soutiens pas dans mon article que « faire une vue en syntaxe PHP native, c’est la vie », loin de là. Un moteur de templates à syntaxe est tout à fait louable, il faut simplement savoir faire la part de choses, avoir les idées claires quant à leurs finalités, et ainsi choisir correctement son moteur. 
    Smarty à l’air d’une belle usine à gaz, et un fichier template peut atteindre un niveau de clarté équivalent sur un moteur bien plus léger ; les raisons qui me poussent à dire ça sont déjà détaillées dans l’article. Pour vous rassurer, j’utilise moi-même un moteur à syntaxe personnalisée. Donc oui, c’est une question de préférence personnelle que je respecte, ainsi je ne parle aucunement d’éviter les moteurs de templates.Enfin, je suis entièrement d’accord avec WordPress, qui est certainement le pire que j’ai pu voir à ce jour en terme de clarté (au point que j’évite encore d’intégrer d’y intégrer des designs).

    Merci pour vos commentaires ;) !

  • http://99ko.tuxfamily.org Jonathan

    Je ne comprends pas vraiment l’intérêt d’utiliser un moteur de templates, quoi qu’il m’est arrivé par le passé d’en utiliser mais je suis revenu aux sources. Bien entendu le principe de séparer les couches est bon, mais on peut aussi le faire avec PHP, comme ça a été dit.
    Et puis pour réagir sur Smarty, la c’est le must. La syntaxe de ce moteur assez complexe par rapport à d’autres, ne fait que rajouter une couche, un langage supplémentaire dans le projet.
    Et le pire est qu’il permet de travailler directement sur des objets, de faire pleins de choses comme des conditions, hors ce n’est pas aux templates de se charger de la partie « logique » mais au contrôleur…