Les avantages d'utilisation d'un système de template dans une application ne sont plus à démontrer. Les principaux arguments des détracteurs des moteurs de templates, sont principalement :

  • Pourquoi utiliser un moteur de template, une nouvelle "machine à gaz", alors que finalement, PHP peut être considéré lui même comme un moteur de template.
  • Cela nécessite d'apprendre un nouveau langage etc...

Ce en quoi ils n'ont pas tout à fait tord. On pourrait donc utiliser un système reposant uniquement sur des fichiers purement PHP, et ne pas avoir à utiliser ce monstre qu'est Smarty avec ces plus de 2000 lignes de codes à inclure à chaque fois dans ses pages web (4000 si on compte son compilateur de template).

Mais personnellement, il y a des choses qui me gênent dans les templates pures PHP.

  • Un template php est consituté essentiellement d'instructions <?php echo $blabla?> : c'est super lourdingue à écrire, mais aussi à lire. (Sans compter que ça donne du fil à retordre pour les développeurs d'éditeurs HTML wysiwyg, n'est-ce pas Daniel ? ;-) )
  • Comme c'est du PHP, le développeur peut avoir la tentation d'y faire tout ce qu'il veut, en particulier des traitements métiers, des requêtes SQL etc, ce qui n'est absolument pas le but d'un template (cf le sacro saint découpage du code en couche, pour une meilleure maintenance et une évolution facilitée).

D'un autre coté, si on prend un moteur comme smarty, il est vrai qu'on a une nouvelle syntaxe à apprendre, qu'il est obligé d'embarquer un parser super lourd pour interpréter le contenu du template (bien qu'il se rattrape en gardant dans un cache une version PHP du template). Mais il a un système de plugin intéressant, des fonctionnalités intéressantes qui facilitent le travail et l'écriture des templates.

J'ai donc décidé pour le moteur de Jelix d'avoir le meilleur des deux mondes :

  • les instructions, les echos ne sont pas dans un <?php ...?> mais entre accolades, comme dans la notation smarty : ça fait des templates beaucoup plus léger à lire.
  • les instructions à l'interieur des accolades : c'est du PHP. Pas de nouveau langage à apprendre. Juste quelques éléments de syntaxe supplémentaires à savoir.
  • Le moteur de template vérifie la syntaxe, avec le tokenizer PHP :
    • il permet ainsi d'interdire les dérives que j'ai signalé : on ne peut pas tout utiliser de PHP. Seulement principalement les instructions de contrôle, de structure (if, foreach etc..)
    • il permet d'utiliser une syntaxe un peu exotique pour certain cas, comme par exemple {$foo} comme dans smarty, pour faire un echo de $foo, ou encore {@myModule~une.locale@} pour faire un echo d'une chaîne localisée ( myModule~une.locale étant la clé de la chaîne ). Et bien sûr, on peut combiner tout ça, faire de la concaténation : {@modul~une.cle.$dynamique@."-".$uneAutreVariable}.
    • il permet une analyse beaucoup plus rapide que dans Smarty puisque c'est PHP lui même via le tokenizer qui se charge de parser les instructions !

Ce n'est pas tout, comme dans Smarty, on peut ajouter ses propres balises {foo} avec un système de plugin carrément analogue, utiliser des modificateurs (j'adore cette réutilisation du principe du pipe des shells unix) et les templates sont "compilés" sous forme de fichier pur PHP et mis en cache pour que le moteur évite d'avoir à faire l'analyse à chaque utilisation d'un même template. Le tout en moins de 450 lignes de code. Pour en savoir plus, lire la doc.

Le moteur de template de Jelix a quelque dépendance avec le framework (normal..). Et je n'ai pas le temps pour le moment d'en faire un moteur "standalone", même si c'est tout à fait envisageable. Par exemple : j'ai pu l'adapter facilement pour une version experimentale de Copix 2.3 et ça fonctionne à merveille. Un jour, si j'ai le temps, je ferais une release de cette adaptation... (quoique, j'hésite... eh eh, coucou l'équipe Copix ! ;-) ).

Update : le moteur de template jTpl existe maintenant en version standalone.