Leçon de PHP n°2.3 : Les Templates

Retournement de veste !

Il paraît qu'il n'y a que les cons qui ne changent pas d'avis. Cette doctrine s'applique également, et je dirais même "de surcroît", aux développeurs. Il est important pour un développeur, voire essentiel, de savoir réviser son jugement et de prendre du recul au sujet de certaines méthodes. C'est pour cela qu'aujourd'hui, je vais vous raconter comment j'ai retourné ma veste au sujet des moteurs de templates...

Il y a de cela deux ans, j'utilisais pour un client, et un peu pour moi-même, le CMS Drupal. C'est un outil de gestion de contenu très bien développé, avec une excellente architecture, très modulaire (un peu trop même). Tout fonctionne à base de "noeud", et ces noeuds peuvent en composer d'autres. On retrouve là la notion d'objets, mais elle est mise en application sur du contenu, sur des documents, de différents types. Bref, ce CMS utilise un moteur de template nommé PHPTemplate, que je n'aimais pas trop car je trouvais qu'il mélangeait trop le code HTML et le PHP... Je préfèrais VTemplate, qui fonctionnait grâce aux balises de commentaires HTML mais je reviendrais sur ces détails plus tard. Je n'étais pas super friand de cette méthode non plus, mais elle m'apparût tout de même "propre" et je l'ai très souvent utilisé dans mes projets jusqu'à aujourd'hui. Oui, aujourd'hui je dis adieu à VTemplate, adieu à Smarty, que j'avais été forcé d'utiliser à un moment, adieu à tous ces moteurs. Bon vent! En effet, en parcourant l'excellent PHP Patterns, site assez complet et très bien écrit (en anglais) au sujet de l'implémentation de Design Patterns en PHP, à la recherche de quelques infos pour une prochaine leçon, je suis tombé par hasard sur un article traitant du sujet des moteurs de templates. Cet article, en anglais, m'a permis de comprendre pourquoi je persistais depuis tout ce temps à utiliser une méthode qui au fond ne me plaisait pas, pourquoi ? Mais avant de vous expliquer cela, revenons un peu en arrière et regardons ce qu'est un template.

Une tempe plate ? (Je sais... elle était facile celle-là...

Le mot "Template" désigne, en anglais et au sens informatique, un gabarit. Le Template doit répondre à l'origine au besoin de séparer la logique d'affichage de la logique d'exécution, ou de traitement si vous préférez. En d'autres termes, pour bien développer, au sens "en mettant en oeuvre de bonnes pratiques", il faut récupérer et manipuler ses données d'un côté, et organiser leur affichage de l'autre. Cela permet, d'une part, d'avoir un code lisible et propre, et d'autre part, de rendre plus aisée la réutilisation du code ou de changer l'un ou l'autre de ses composants sans difficulté, et sans régression. L'extensibilité (c'est moche comme mot en français) est également grandement facilitée.

Un conflit d'intérêt ?

Mais l'autre intérêt de l'isolation de la logique d'affichage, c'est de pouvoir faire travailler le "Web Designer", ou l'intégrateur XHTML si vous préférez (personnellement je préfère ce terme moins pompeux et plus précis), sur ce qui le concerne, le XHTML, et de laisser le développeur travailler sur son code sans interférence avec le travail de l'intégrateur. Ainsi l'intégrateur fournit le Template, qui contient donc du code XHTML (le cas le plus fréquent), le développeur l'incorpore à son application, en s'étant d'abord mis d'accord, bien entendu, avec l'intégrateur pour définir les données "dynamiques" qui transiteront de l'un vers l'autre : les textes, les zones qui se répèteront à l'affichage (ex: listing), etc... Comme le précise l'article cité ci-dessus, le développeur (pas tous bien sûr...) a tendance à prendre l'intégrateur pour un idiot : tandis que le développeur manipule un "vrai" langage de programmation, l'intégrateur, lui, ne manipule "que" des balises XML (le XHTML étant un XML). En gros, chacun son métier, et les chèvres seront bien gardées. 

- "De toute manière, tu sais pas comment on trait leur lait alors ne cherche pas à comprendre, c'est trop compliqué pour toi alors retourne faire mumuse avec tes balises Legos et tes CSS Playmobil .", s'exclama le développeur orgueilleux.

Du coup, le développeur met tout en oeuvre pour ne pas laisser une seule occasion à l'intégrateur de voir ne serait-ce qu'une ligne de code de son langage fétiche, à la place il utilise une syntaxe de substitution : celle d'un moteur de template. Il fait cela pour deux raisons : éviter d'avoir à gueuler comme un putois sur l'intégrateur s'il touche ne serait-ce qu'à un caractère de ce code si précieux, et pour que l'intégrateur ne sache jamais qu'en fait le boulot du développeur n'est pas si compliqué qu'il en a l'air, que son code est compréhensible par quiconque possèdant des notions d'anglais, ce que l'intégrateur possède vu qu'il fait du XHTML... Et donc il préfère lui montrer une syntaxe de cochon, une qui fait peur.

Et le développeur se croit si malin que pour intégrer le template de son collègue et y affecter ses propres données dynamiques, en conformité avec le traité de paix qu'ils ont signé, il passe le plus souvent par une librairie permettant de traiter le template et de remplacer les données à l'intérieur. Pourquoi réinventer la roue, alors que les mésopotamiens l'ont fait pour nous ? Le développeur se contente donc de préciser à ce moteur quel fichier de template utiliser, et quelles variables y intégrer. Et roule mon moteur, affiche-moi le résultat. "Fingers in the nose", se dit-il, tout fier, contemplant ses trois lignes de code.

Toute ressemblance avec des personnes connues n'est pas fortuite.

Alors quoi? Certains connaissent et se reconnaissent dans ce que je raconte, travaillent de cette manière tous les jours, et en sont satisfaits, alors pourquoi autant de mépris, me direz-vous? Du mépris, il n'y en a guère dans mes propos sachez-le bien. Sachez aussi, et surtout, que comme beaucoup, j'ai employé cette méthode et l'employait encore hier, alors même que je porte à la fois la casquette du développeur et celle de l'intégrateur. Cela veut-il dire que mon côté développeur me prend pour un crétin d'intégrateur ? Avec deux casquettes, y'a peut-être de quoi avoir l'air con... m'enfin c'est une autre histoire.

Pourtant, comme je l'ai dit en introduction, et je ne dois pas être le seul dans ce cas-là, je n'ai jamais vraiment aimé les moteurs de templates, comme Smarty par exemple. En effet, j'ai toujours senti le besoin, évident, de pouvoir attribuer des variables à mon template, et de définir des zones à répéter, mais Smarty va plus loin en intégrant carrément des fonctions DANS le template, alors qu'elles n'ont rien à faire là !?! Surtout quand elles sont intégrées avec une syntaxe supplémentaire : un langage différent de PHP et de l'XHTML, même si on pourrait s'y tromper vu qu'il est souvent présenté sous forme de balises... Cette nouvelle syntaxe va être "décodée" ("parsée" étant plus juste mais pas forcément compris de tous) par le moteur de template. Ce qui demande des ressources supplémentaires et pas des moindres vu qu'il ne s'agit pas d'un langage "natif" pour le serveur. Concrètement le moteur va faire un énorme "chercher/remplacer" et récursivement quand il s'agit de boucles. Afin de pallier à cette perte de performance, les moteurs de template, écrits par des développeurs malins également, intègrent quasiment tous des systèmes de cache, permettant ainsi de ne pas exécuter les processus de traitement des templates quand ceci ont déjà été traités auparavant (et cela arrive souvent), malins je vous disais. Pour ma part, j'avais donc fait le choix de VTemplate, un moteur français plutôt "léger", plus maintenu depuis plusieurs années mais offrant une syntaxe basée sur les commentaires XHTML, donc compréhensible pour mon crétin d'intégrateur, un bon compromis donc, me disais-je. Et mon génie de développeur se voyait passer des variables et répéter des zones grâce à ce moteur tout en gardant en tête que quelque chose clochait avec ce fonctionnement, au fond de lui il savait que qu'il y avait quelque chose de dégueulasse, comme un arrière-goût de maroilles oublié au fond du frigo alors qu'on mange des fraises des bois...

Oui aux Templates ! Non aux Moteurs !

La véritable question soulevée ici est : pourquoi utiliser un moteur de template alors que … PHP en est déjà un à l'origine !

Et oui... PHP est un moteur de template, Rasmus, son créateur, l'a un peu créé pour cette utilisation au départ (mais pas que...). Vous avez des doutes? Demandez-vous pourquoi le code PHP possède cette particularité de pouvoir être écrit et exécuté en plein milieu d'un document HTML... ?

Le soucis c'est qu'au fil des demandes de ses amis, Rasmus a implémenté dans PHP des structures conditionnelles (if, else...), des boucles (for...foreach...while...), et PHP a commencé à devenir un langage de programmation à part entière à partir de là, mais à l'origine, il ne s'agissait que de pouvoir écrire des scripts de manière simple et rapide à l'intérieur de pages HTML. C'est cette particularité qui en a fait un langage facile d'apprentissage et rapidement adopté par beaucoup.

Le revers de la médaille, c'est que du coup n'importe qui peut faire n'importe quoi avec PHP...
- "Comme de développer des moteurs de templates ?"

Oui, enfin il faut tout de même rendre à César ce qui est à César. Les moteurs de templates ont tout de même un bon côté : ils ont "appris" à beaucoup de développeurs, y compris moi, à isoler la logique d'affichage du reste, ce qui est bien en soit, c'est la méthode pour y parvenir qui ne l'est pas.

Retour aux sources

Souvenez-vous de vos premiers scripts (ou de la première leçon de PHP disponible ici-même). On utilisait PHP comme PHP nous le permettait et nous le permet toujours, c'est à dire à l'intérieur de pages HTML. Et puis, de la même manière que Rasmus a ajouté des fonctionnalités, nous avons ajouté des traitements sur nos données tout en gardant cette mauvaise habitude d'écrire dans les pages HTML, allez … avouez-le. Qui n'a jamais écrit session_start(); ou mysql_connect(); avant le DOCTYPE ou, mieux encore, avant "<html>" ? Ou alors un include('header.php'); ?

Jusqu'au jour où c'en est devenu problématique, l'alternance de HTML et de PHP s'est mise à nuire fortement à la lisibilité du code, et à la réutilisation, et à l'extensibilité, ouf. En même temps, l'extensibilité on s'en foutait un petit peu n'est-ce pas? C'est surtout qu'au fur et à mesure qu'on code du PHP, on veut mettre en place de bonnes pratiques, et cette méthode n'en était clairement pas une. Alors on se penche du côté des moteurs de template, tout naturellement... Mais l'utilisation de moteurs de template a produit l'effet inverse, à trop vouloir séparer la logique de présentation on en a oublié que PHP était fait pour ça. Pourquoi rajouter des couches supplémentaires à un langage interprété (non-compilé)…

- "Alors oui, je vois tout à fait ce que tu veux dire, c'est bien joli mais on fait comment? On va tout de même pas se remettre à écrire du PHP dans le HTML?"

Et pourquoi pas? Souvenez-vous qu'à l'origine le besoin est de séparer les logiques (affichage et traitement des données), pas les langages! Ce sont les moteurs de templates et les développeurs qui ont introduit cette aberration. Personne n'a dit qu'il fallait faire totalement disparaître le PHP des templates ? N'imaginez pas non plus qu'il s'agisse d'une méthode de "puriste", sans prétendre en être un, il me semble qu'être puriste ce n'est pas utiliser une méthode d'abstraction lorsqu'un langage l'implémente déjà d'origine.

- "Et ce crétin d'intégrateur? Je lui laisse voir tout mon code PHP? "

Soyons sérieux, deux minutes, pensez-vous réellement qu'un intégrateur serait complètement désorienté si il voyait le code suivant ?

Code:

<h1><?php echo $titre; ?></h1>

Pas plus que lorsqu'il voyait celui-ci :

Code:

<h1>{#titre}</h1>

Même si cette écriture est plus courte, elle utilise une syntaxe inconnue, en l'occurence cette de VTemplate. Smarty utilise certes un $ (dollar) au lieu du # (dièse) donc ça "ressemble" au PHP, mais d'où viennent ces accolades ? Allez, soyons un peu plus méchant, voici un autre exemple d'utilisation avec Smarty cette fois-ci :

Code:

{*
<select name="company">
 {html_options options=$vals selected=$selected_id}
</select>
*}

Honnêtement, je comprend parfaitement ce que ce code doit effectuer, mais j'avoue que je serais embêté si je devais écrire moi-même un template à partir de zéro en utilisant cette syntaxe. Je devrais sans cesse aller faire des aller-retours sur la documentation Smarty. Sachant que je switche souvent entre le XHTML, le CSS, le JavaScript (sans compter le ou les frameworks que je peux employer avec), le PHP et bien entendu le SQL, cela fait déjà 5 langages complètement différents alors non : quand y'a de la place pour 5, y'en a pas forcément pour 6. Mon template devrait être écrit en utilisant une syntaxe que je connais déjà.

- "Et si il touche mon code ?!? "

Il n'y a pas plus de risque qu'avec le code d'un moteur de template, ça plantera le template et c'est tout ! Comme votre logique de traitement n'est pas dans le template, pourquoi avoir peur? De plus, si vous mettez à disposition de l'intégrateur une version de test de l'implémentation de son template, en attribuant des valeurs par défaut, l'intégrateur peut lui-même voir en direct si son template fonctionne toujours.

- "Mais de mémoire... c'est pas toi qui disait qu'il ne fallait pas faire directement des echo mais des return non?"

Rassurez-vous, même si le template fait des echo, rien ne sera envoyé au navigateur car nous utiliserons une petite astuce grâce à la bufferisation de la sortie. Cette fonctionnalité intégrée de PHP, permet justement "d'attraper" le contenu "sortant" de PHP et, si on le désire, de le rapatrier dans une variable, ou d'attendre que la sortie soit "complète" (entête+contenu+pied) avant de l'envoyer au navigateur.

- "Et comment est-ce qu'on gère la cache ?"

Rappelez-vous que les moteurs de templates intègrent des systèmes de cache pour ne pas avoir à faire des choses inutiles. Mais surtout parce que ces choses inutiles sont lourdes.

Pourquoi sont-elles lourdes? Premièrement parce que, comme je le disais plus haut, on demande à PHP de parser le template avec un langage qui n'est pas "natif", celui du moteur. Deuxièmement parce que le moteur de template doit forcément charger à un moment ou à un autre tout le template dans une variable pour pouvoir le traiter, ce qui occupe de la mémoire inutilement.

En utilisant PHP comme moteur de template, nous faisons d'une pierre deux coups : le traitement du template se fait de manière "native", il "parle" en PHP et est donc interprété à la volée, pas besoin d'une interprétation plus claire. De plus nous ne chargeons pas le contenu du template dans une variable pour le traiter vu que PHP s'en charge tout seul, nous utilisons le buffer intégré à PHP. Vous voyez donc que nous n'implémentons rien que PHP ne sache pas déjà faire tout seul. Ainsi l'exécution d'un template sera forcément plus rapide que n'importe quel moteur de template (hormis ceux qui portent le nom mais qui utilisent ce même principe bien entendu).

Pour en revenir à la question du cache, cette méthode ne nous empêche pas d'intégrer un système de cache, cela fera l'objet d'un sujet à part. Ce qui est par contre important à retenir, c'est que dans le cas où le cache n'est pas sollicité (données souvent différentes) un moteur de template sera un véritable frein à l'exécution de votre code.

- "Et si je veux/peux pas utiliser de variable locales ?"

En fait, même si mon exemple donne l'impression d'utiliser des variables locales, il n'en est rien. Enfin, pas exactement, le template va utiliser la fonction extract() pour transformer les variables contenues dans un tableau associatif, en variable locale. Si vous ne voulez pas effectuer cette opération, dans ce cas vous pouvez toujours utilisez echo $this->titre au lieu de echo $titre, ça rallonge juste un peu l'écriture.

- "Concrètement, ça ressemblerait à quoi ?"


Voici un exemple extrêmement basique d'un tel moteur de template, j'ai volontairement ignoré la gestion des exceptions, etc... Le fonctionnement est quasiment le même que celui-ci et vous y trouverez même un exemple d'implémentation d'un système de cache.
Regardez comme cette classe est légère :

Code:

<?php
class Template
{
   protected $fileName;         // Le nom du fichier de template à parser
   protected $vars;         // Contient les variables du Template

   // Le constructeur
   function __construct($fileName = '')
   {
      $this->fileName = $fileName;
   }
   
   // Permet d'attribuer des variables au template
   function setVar($key, $value)
   {
      $this->vars[$key] = is_object($value) ? $value->render() : $value;
      return $this;
   }
   
   // Effectue le traitement et renvoie le résultat
   function render()
   {
      extract($this->vars);            // Extrait les variables en local
      ob_start();                  // Ouvre le tampon de sortie
      include($this->fileName);         // Inclut le template
      $output = ob_get_contents();      // Récupère le résultat dans le tampon de sortie
      ob_end_clean();            // Ferme le tampon et l'efface, donc rien n'est envoyé au navigateur
      return $output;
   }
}
?>

Un exemple simplissime de modèle de template (mypage.tpl) :

Code:

<?php echo $doctype; ?>
<html>
   <head>
      <title><?php echo $title; ?></title>
   </head>
   <body>
      <h1><?php echo $title; ?></h1>

      <?php echo $content; ?>

   </body>
</html>

Et son utilisation donc :

Code:

$myTemplate = new Template('mypage.tpl');
echo $myTemplate   ->setVar('doctype','<!DOCTYPE blablabla>')
            ->setVar('title','Voici le titre de ma page')
            ->setVar('content','Je pourrais également utilisé un autre template directement dans mon contenu')
            ->render();

L'utilisation du template n'est pas plus compliqué qu'avec un moteur et, comme précisé dans le contenu, nous pouvons encapsuler d'autres templates à l'intérieur d'un template. La méthode setVar() détectant si la variable est un objet et en exécutant le traitement à la volée, on peut totalement séparer l'habillage de la page, de son contenu, qui lui-même pourrait être découper en différentes zones.

- "Et les boucles dans tout ça ?"

C'est simple, il suffit de passer le tableau associatif au template avec setVar() et de le boucler dans le template :

Code:

<?php if(is_array($dataList)) : ?>

   <ul>
   <?php echo $dataListTitle; ?>
   
   <?php foreach($dataList as $cle=>$valeur): ?>
      <li><?php echo $cle; ?> : <?php echo $valeur; ?></li>
   <?php endforeach; ?>
   
   </ul>

<?php else: echo $dataNoListTitle; endif; ?>

Et voici les changements dans l'exécution de notre appel au template :

Code:

$dataList = array(1=>'Introduction',2=>'Pré-requis',3=>'Installation',4=>'Configuration',5=>'Hello World');
$dataListTemplate = new Template('datalist.tpl');
$dataListTemplate   ->setVar('dataListTitle','Table des Matières')
            ->setVar('dataNoListTitle','Document vide')
            ->setVar('dataList',$dataList);

$myTemplate = new Template('mypage.tpl');
echo $myTemplate   ->setVar('doctype','<!DOCTYPE blablabla>')
            ->setVar('title','Voici le titre de ma page')
            ->setVar('content',$dataListTemplate)
            ->render();

Concernant les boucles, dans tous les cas il y a deux méthodes bien distinctes : soit on fait la boucle en dehors du template en ouvrant/attribuant/fermant les zones du template, soit c'est le modèle de template qui possède lui-même une directive de boucle sur une seule donnée attribuée. Cette seconde option allège le code PHP mais alourdit en contre-partie le modèle. Lorsque la boucle se complexifie un peu, une alternative consisterait à séparer ce morceau et en faire un modèle à part, là aussi il y a une contre-partie : le modèle ne permet pas d'avoir une vue d'ensemble du code traité, mais de toute manière ce n'est que très rarement le cas, on sépare très souvent la mise en page globale du reste. L'autre inconvénient, moins gênant, c'est côté PHP où l'on fait deux instances au lieu d'une, mais très souvent on se rend compte que c'est plus pratique ainsi car le code s'y prête de lui-même.

Et côté performance ?
Afin de ne pas raconter trop de conneries, j'ai fait quelques tests de façon très simple : une triple boucles créant des cellules <td></td> dans des rangées <tr></tr> dans tes tableaux <table></table>. Plus précisemment : je demande à générer 10 tableaux, de 100 rangées chacune, de 100 cellules chacunes, et dans chaque cellule est injecté un md5 d'un random, histoire de corser un peu le tout. Il a fallu augmenter la limite de mémoire pour PHP car ça fait tout de même beaucoup de boulot 100 000 cellules Si j'ai du temps un jour, j'essayerais de faire un test plus parlant avec un "vrai" contenu composé de plusieurs modèles différents avec des appels de variables concrets, mais cela veut dire créer les templates pour chacun des langages... La flemme.

Tous les tests ont été effectués sur la même machine, un MacBook Pro Unibody @2,4Ghz et 2Go de ram, qui était à la fois le serveur (sous XAMPP) et le client (sous Safari 4), mais ça rentre peu en ligne de compte, c'est juste pour vous donner un ordre d'idée.
J'ai fait les requêtes à plusieurs reprises, j'ai retenu les 5 premières pour faire une moyenne, les suivantes servant à confirmer la "tendance".

VTemplate (sans cache) : 5.75 sec en moyenne, 5.73 au mieux, 5.77 au pire

Smarty sans la cache : 1.5 sec en moyenne, 1.45 sec au mieux, 1.62 au pire.
Smarty avec la cache : 1.34 sec en moyenne, 1.25 sec au mieux, 1.59 au pire c'est à dire la première requête, si je ne la compte pas...
1.28 sec en moyenne si on exclut la première requête, celle qui créé la cache.

Conclusion 1 : VTemplate n'est pas fait pour les grosses générations...
Conclusion 2 : La différence entre avec et sans cache pour Smarty n'est vraiment pas énorme, je m'attendais à mieux.
Voyons maintenant comment s'en sort notre classe Template(), où l'on a pas encore cherché à optimiser quoique ce soit...

Template() : 0.974 sec en moyenne, 0.95 sec au mieux, 1 sec au pire.
C'est un plutôt un bon score, et il est vrai que Smarty s'en sort pas mal du tout pour le coup.

Au niveau de l'occupation de la mémoire, le podium est inversé :
- VTemplate a demandé 22 Mo d'allocation.
- Smarty en a demandé 28 Mo.
- Template() est un gros naze à ce niveau-là : 38 Mo.

Alors j'ai voulu savoir pourquoi, j'ai changé le processus de test en n'effectuant non pas un random + un md5 mais uniquement l'écriture d'un texte identique dans chaque cellule : un simple "test". Et les scores sont totalement différents :

Template() n'a demandé que 14 Mo là où Smarty en demandait 26, tandis que VTemplate se contentait de 7 Mo.
Par contre, bien qu'économe en mémoire VTemplate s'en sort toujours avec un score horriblement mauvais : [b]4.7 sec en moyenne...
En revanche, l'écart se creuse entre nos deux finalistes :
Smarty a exécuter ces 100 000 cellules "test" en 0.77 sec en moyenne (0.8 max)
Template() l'a fait en 0.27 sec, c'est à dire presque 3 fois moins de temps, tout en demandant presque deux fois moins de mémoire.

A côté, j'ai voulu voir sur des tests plus "légers", la classe Template() peut s'avérer plus de 20x plus rapide que VTemplate, et 5x plus rapide que Smarty.
En vérité, en diminuant le nombre de cellules à afficher, Template() creuse encore plus l'écart, allant même jusqu'à être 10x plus rapide que Smarty pour afficher tout de même 200 cellules...

Conclusion
Ce n'est pas la peine de vous faire un graphique. Il est évident que les développeurs de Smarty ont fait un boulot formidable, mais les tests le montrent bien : un template utilisant une sur-couche ne peut tout simplement pas être aussi rapide qu'un template "natif". Qui plus est, il ne vous permettra jamais d'accéder aux données de manière aussi naturelle que vous pourriez le faire avec PHP, bien au contraire ils peuvent provoquer de la confusion. Un exemple : l'accès au tableaux associatifs avec Smarty se fait avec l'utilisation du point "." (ex: $tableau.$key ) ce qui en PHP correspond à une concaténation, l'équivalent en PHP ($tableau[$key]) n'est possible que si la clé est un entier et encore, il ne faut pas que ce soit une variable...

Sachez qu'il existe bien entendu des moteurs de template qui utilisent déjà cette méthode, je parlais au tout début de Drupal, mais j'ai cru voir sur le net que Savant était du même acabit.

Il existe également des méthodes alternatives, la meilleure étant très certainement l'utilisation de XSL avec XSLT, en tout cas c'est la méthode plus propre ça c'est certain. Ce couple permet en fait la transformation d'un fichier XML vers un autre type de document, comme du XHTML, ou tout autre chose, grâce au fichier XSLT, "T" pour Transformation, qui décrit comment traduire la source. Ces formats sont des standards, ils ne disparaîtront pas de ci-tôt et parier sur eux c'est gage de pérennité. C'est évidemment puissant, en terme de fonctionnalité, je ne sais pas du tout ce qu'il en est des performances avec PHP, elles sont probablement bonnes, mais par contre c'est horriblement compliqué... Disons surtout que "même" si c'est du XML, le XSLT est très particuler, et là encore, il vous faudra apprendre une syntaxe supplémentaire.

Tout dépend de l'ampleur de votre projet, mais faites le bon choix dès le départ car changer de moteur de template en cours de route est une tâche plutôt chiante. Je migre une quinzaine de modèles en ce moment même...