Utilité des langages de templates en PHP

Les langages de templates sont apparus en PHP il y a près de 10 ans. Leur utilisation s’est répandu, mais sont-ils vraiment utiles ? PHP n’est il pas par définition un langage de template ?

Pourquoi cette bête étrange ?

L’objectif initial est de séparer la couche de présentation de la couche applicative. Leurs fervents défenseurs mettent en avant la simplicité de la syntaxe pour les templates, et le fait que les limitations imposées par les structures du langage permettent de garantir cette stricte séparation.

Cependant, le prix à payer est disproportionné.

Compilation de templates

La compilation de template est un abus langage, on devrait plutôt parler de transformation en langage interprété. Je connais à ce jour aucun système de template qui est compilé au sens strict du terme, ce sont uniquement des fichiers PHP qui sont générés.

Le coût de cette opération est important, il nécessite de mettre en cache, généralement des fichiers, le code ainsi généré. Une modification dans le template implique de facto la « recompilation » du template.
L’accès aux ressources externes peut parfois poser des problèmes. Prenons l’exemple d’un fichier de configuration, on lit les données et on les utilise dans le template. On change ces données de configuration, est ce que les données sont stockés directement dans le template, et donc nécessite une « recompilation », où sont ils sont réinterprétés lors de l’exécution du template ? Pas de réponse absolue dans ces cas là, cela dépend du moteur de template, et parfois même de la ressource utilisée.
Le cout de compilation d’un template peut parfois être prohibitif, il est difficilement concevable d’aller recompiler les templates sur un site en production. Dans notre cas, une donnée de configuration affectant l’ensemble des templates nécessiterait la recompilation de tous les templates. Prendrez vous ce risque sur un site à fort traffic ?

Une syntaxe simplifiée

L’argument de vente des langages de template est la syntaxe simplifié qu’elle offre. Mais ici, on a affaire à une légende urbaine.
PHP est historiquement un langage de template, c’est d’ailleurs ce qui a fait son succés.

Excepté, les balises d’ouvertures, on trouve peu de différences dans les structures de contrôles. La richesse fonctionnelle est généralement plus restreinte.
Cependant, on trouve beaucoup plus d’outils qui permettent de manipuler du PHP qu’un langage de templates quel qu’il soit. J’ai n’ai pas vu à ce jour un module pour les templates avec une intelligence de code suffisante dans les éditeurs classiques de tout développeur (Eclipse, jEdit, vim, emacs, …).
Par contre, ces modes existent bien pour PHP. Donc, sur l’édition du code , il est difficile d’avoir un gain de productivité. Personnellement, je constate plutôt une baisse.

Séparation contrôle / présentation

Le dernier argument que j’ai entendu en faveur des moteurs de template, et qu’il oblige à la séparation stricte entre le contenu et la présentation.
Il est vrai que la limitation fonctionnelle ne permet pas de faire des traitements sur les données, mais cette limitation est tellement forte qu’il souvent plus simple de pré-macher le travail au niveau du contrôleur(ou de passer par des helpers) pour ne pas avoir à trouver des combines dans le langage de templates.
A contrario, cette non-limitation en PHP a son revers, il est possible de mettre de la logique de traitement dans les templates, mais le bon sens l’emporte généralement.

Après avoir étudié tous les arguments des défenseurs, des langages de templates écrit en PHP, je n’y vois toujours pas un seul avantage.

Category: Culture Web, Intégration

Étiquettes : , , ,

- 10 juin 2009

Comments

  1. Ha ca polémique entre Blog 🙂

    Effectivement c’est lourd et cela nécessite un système de cache. Mais il faut considérer que sur des gros projets, à forte traffic, il faut tot ou tard un système de cache, avec toute la complexité que cela entraîne. Dans ce contexte, la compilation des templates reste un détail dans le processus, puisque la génération de pages statiques ou pseudo statiques est inévitable.

    Il faut également considérer d’autre aspect, liés aux gros projets, qui donnent du sens aux systèmes de templating :
    – La nécessité de travailler en équipe développeurs (moteurs PHP) / intégrateurs (template / xHTML / CSS) : cela facilite le partage de compétence et les interventions des graphistes intégrateurs
    – La nécessité d’indépendance entre le langage moteur, et le langage de présentation. Cela facilite les montées de versions (imaginons un CMS qui migre de PHP4 à PHP5, on réécrit le moteur, et pas les millions de templates produits sur les milliers de sites)

    En conclusion, il faut penser en logique « gros projet », « équipe pluridisciplinaire », « maintenance long terme », pour envisager l’utilité des templates et le gain induit. Dans le cas contraire (projet freelance), c’est effectivement cher payé.

  2. Je savais que tu réagirais en moins de 2 minutes.

    La dépendance vis à vis des monté de version je suis plutôt d’accord, mais quelque soit le moteur de template (PHP directement, ou ceux écrit en PHP).

    Par contre pour la gestion de cache, je ne comprend pas l’avantage. Les langages de templates ne fournissent que du code PHP. On décale juste le problème.
    Après les solutions pour mettre en cache du op-code PHP, des résultats sérialisés, des fichiers textes sont multiples (Memcache, APC, XCache, Zend_Platform, … ), et sont relativement simple à mettre en place.

  3. Damned, c presque un chat ! 15 min pour réagir !

    Pour la gestion du cache, ce n’est pas un avantage, mais pas un inconvénient non plus (sauf si le code généré est mal optimisé). Je précisais juste que comme le cache devient nécessaire tot ou tard, ce n’est pas le templating qui motive le besoin en cache, mais la nature des projets à forte audience.

  4. je rajouterais que certains langages de template permettent aussi d’améliorer un peu la sécurité pour 2 raisons :
    1. les templates « s’éxécutent » dans une espèce cage où toutes les données ne sont pas accessible facilement, ça complexifie un peu les possibilité d’injection
    2. certains moteurs de template échappent systématiquement (sauf demande contraire du développeur) les données provenant de variables évitant ainsi une bonne partie des failles XSS. Je pense en particulier au système de context [1] du composant Template des eZ Components

    [1] http://ezcomponents.org/docs/tutorials/Template#contexts

  5. J’ai peut être oublier de préciser que je me plaçais dans un contexte professionnel, donc avec un modèle MVC cohérent, et par conséquent un composant de Vue dédié aux templating.
    Donc, on retrouve la notion de sandbox que tu évoque, et le filtrage automatique (ou non) des données.

    Je remet pas en cause l’avantage d’avoir une couche dédié au templating, elle est certaine (séparation intégrateur / développeur, sécurité, … ).

    Ce qui m’insupporte dans Smarty, eZPublish, eZComponents … pour ne pas les nommer, c’est la syntaxe, la notion de « compilation », l’absence d’outils, … .

  6. « J’ai peut être oublier de préciser que je me plaçais dans un contexte professionnel, donc avec un modèle MVC cohérent, et par conséquent un composant de Vue dédié aux templating. »

    c’est marrant, il y a encore quelques années j’aurais dit comme toi mais je me rend compte que même en environnement pro SSII, le « donc » de ta phrase est très optimiste voire utopiste crois moi 🙂
    et même avec une couche template avec un langage très restrictif, le développeur moyen arrive toujours à faire n’importe quoi, je te laisse imaginer le carnage sans langage de template…

  7. @Damien : Sylvain n’a pas encore fait le deuil d’un certain nombre de chose à propos de l’informatique professionnelle. Ne lui en dis pas trop, ca pourrait le briser 🙂 Je m’en occupe !

    Par ailleurs, l’effet pervers du langage de templating, c’est qu’il diminue potentiellement le niveau du fameux « développeur moyen », ce qui au final, peut parfois générer un « carnage » tout aussi dévastateur en temps de travail et en performance… Cependant le carnage reste effectivement confiné (sécurité), c’est déjà ca de gagné.

  8. Benjamin Franklin
    2 juillet 2009 - 23 h 31 min

    Celui qui est prêt à sacrifier un peu de sa liberté pour plus de sécurité ne mérite ni l’une ni l’autre, et finit par perdre les deux.

    Cette citation de Benjamin Franklin résume bien la problématique des langages de templates en PHP.

  9. Comme cela a déja été dit précédemment, il est coutume de séparer le traitement de la présentation. Aussi le rôle des templates est tout simplement d’afficher des variables qui lui sont passées en paramètres. Ceci revient a faire un simple en php.
    De ce fait, il est légitime de douter de l’utilité d’un langage de template complet et/ou complexe, qui comme l’a très bien dit Truffo peut réduire la vélocité de notre application, alourdir notre code et être source de bugs.

  10. Tiens, un vieux sujet que j’ai zappé 🙂

    Je ne suis pas trop fan des moteurs de template pour ma part… sachant que PHP est déjà un langage de template (oui je sais, je sors l’argument des anti smarty mais bon, je suis d’accord avec eux).

    Secondo, quand je vois sur ezPublish la complexité du langage de template, je déplore de ne pas pouvoir justement coder en PHP… et j’en passe et des meilleurs. PHP est assez simple pour entrer dans un template, suffit de ne pas coder du fonctionnel dans le template et ça reste très très clair.

    Tercio, on tombe très souvent sur des cas compliqué avec des langages de templates… le code devient justement vite illisible à cause de ça.

    Et enfin, en ce qui concerne le cache, un bon framework doit permettre le paramétrage, utiliser APC (et pas seulement l’activer… non non, mais utiliser l’API cf. http://www.copix.org qui l’utilise parfaitement bien)

    Oui, copix permet d’utiliser Smarty… mais je vois de plus en plus de dev arrêter d’utiliser ce truc pour revenir à du template PHP bien fait.

    Bref, question de gout, question de logique… chacun son choix: le mien est fait ! 😉

  11. Énorme cet article de Fabien * symfony * Potencier !

  12. Ouais, je l’ai lu, c’est vrai que le else de boucle est un vrai manque dans la langage PHP, et pas seulement en mode moteur de template.

    Par ailleurs, pour l’échappement des caractères, je ne peut pas être d’accord sur l’auto-échappement, prenons l’exemple simple mais désormais classique de faire un simple lien dans un nouvelle fenêtre accessible. La règle d’échappement n’est pas identique entre le title et le contenu entre la balise, pourtant une partie du texte est identique. Donc avec un « autowash », tu doit « dewasher » pour « rewasher » correctement.

    Pour ce qui est de la sandbox, ça donne l’air d’avoir de la sécurité,pourtant il n’en est rien on peut toujours rajouter des balises, des opérateurs qui vont être appeler dans les templates qui feront exécuterons le code PHP que l’on a voulu caché. C’est vraiment de l’illusion de sécurité.

    Sinon, la page montre quand même quelque chose d’intéressant, seul le PHP à une coloration syntaxique correcte.

  13. J’écrirais sûrement un article sur ce même sujet, en abordant notamment Twig que je commence à suivre de près. Pour moi l’intérêt se situerait dans une syntaxe universelle indépendante du langage en backend ; syntaxe évidemment prise en charge à court terme dans tous les IDE.

    Bien sûr, on parle d’idéal…

    Ton nouveau lecteur

  14. Il y a un truc qui m’échappe. Tout le monde s’accorde à dire que le PHP souffre de certaine carence pour les templates, et que les langages de template apporte une solution à ce problème. Mais pourquoi PHP n’intégrerer pas directement toutes les fonctionnalités directement dans la plate-forme ?

  15. Bonjour,

    pour ma part j’utilise un moteur de template maison pour ces raisons :
    – simplification du code. Par défaut un {name} correspond à un name); ?>. C’est pour moi un raccourci important, qui évite bien des oublis coté code.
    Toutefois avec cet échappement automatique il n’y a pas l’impact « wash / dewash / rewash » que vous indiquez : si je mets {url:name} le htmlspecialchars sera simplement remplacé (à la « compilation ») par un rawurlencode.
    En effet on reprend l’utilisation des « modifiers », un peu comme on peut le trouver dans le moteur de template Flexy.

    • bonne intégration HTML. J’aime ce genre de syntaxe : {userName}, qui m’évite d’avoir à placer l’accolade fermante de mes ifs, foreach ou autres blocs. Le XHTML est balisé, donc on utilise avant tout les balises déjà présentes.

    • forte isolation. Mon but à l’origine était de permettre aux membres d’utiliser leurs propres templates, sans compromettre la sécurité du site (pour une plateforme de blog mutualisée par exemple). Ainsi le template n’a strictement accès qu’aux données qu’on lui fourni, et absolument rien d’autre.

  16. note : mon précédent commentaire s’est vu tronqué des balises PHP et HTML, et est donc incompréhensible… Raison de plus pour utiliser un bon échappement à l’affichage plutôt qu’une hâche à la saisie 😛

  17. Raison de plus pour utiliser un bon échappement à l’affichage plutôt qu’une hâche à la saisie

    Tu peut potentiellement te prendre beaucoup d’attaque de type XSS même en échappant les caractères à la sortie.

    Il faut absolument faire les 2 : c’est la base du Web quand même, je dirais même qu’il faut surtout la hache à la saisie. Ensuite, le langage autorisé est le HTML dans les commentaires (Je t’accorde l’erreur d’ergonomie qui ne donne pas cette information, je la corrigerais).

    Ensuite, pour les accolades, il existe la syntaxe avec les « : » qui est faite pour cela.

    Par contre, l’argument sur la forte isolation me fait plutôt rire, il ne faut pas confondre la vue d’un modèle MVC et un moteur de template. L’isolation forte entre la vue et le reste est souvent nécessaire comme tu le dit, mais le langage de template n’apporte absolument rien à ce niveau.

    Après, tu dit que le template n’a strictement accès qu’aux données qu’on lui fourni, et absolument rien d’autre, si tu savais le nombre de fois où j’ai vu des contournements par l’intermédiaire d’un proxy ajax pour récupérer des donnés pour contourner cette limitation contre-productive, ça fait simplement froid dans le dos.

    Dans un exemple qui m’a particulièrement marqués, l’intégrateur avait besoin d’une liste d’utilisateurs en fonction de certains paramètres, il avait besoin de leur nom, de leur email et de leur numéro de compte client, il attendait le développement de la fonctionnalité qui ne venait pas. Alors, il a décidé de passer par un proxy Ajax pour gagner du temps. Il indique clairement la raison dans le commentaire du code. Je cite « Le temps que quelqu’un me implémente l’opérateur que j’ai besoin et qu’il le commit, je le site sera déjà en ligne ».

    De ce point de vue, je rejoint Benjamin Franklin en disant : « Celui qui est prêt à sacrifier un peu de sa liberté pour plus de sécurité ne mérite ni l’une ni l’autre, et finit par perdre les deux. »

  18. Je me posais aussi la question de l’utilisation des moteurs de templates, et deux arguments m’ont touchés dans vos propos :
    – la forte isolation : il me semble intéressant d’empêcher par exemple l’exécution d’une requêtes SQL dans un template, surtout si on compte laisser aux utilisateurs la possibilité d’écrire leurs templates ; Or, comment l’empêcher, si l’on utilise du PHP dans les vues?
    – bonne intégration HTML : Il faut reconnaître que PHP est un langage fort verbeux, ce qui n’est pas très pratique lorsqu’on l’intègre dans du HTML.

    Cependant, si l’on part du principe que les templates sont utiles lorsque plusieurs personnes travaillent sur un même projet, le manque de standardisation de ces moteurs est très gênante : chacun utilise le moteur qui lui plait le plus, et il n’est pas évident d’en trouver un que tout le monde puisse prendre en main facilement…

    Le « top » serait de pouvoir n’utiliser uniquement que quelques fonctions PHP (les conditions, boucles, affectations), mais pas toutes les autres (mysql_* par exemple)

Laisser un commentaire

Your email address will not be published / Required fields are marked *