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.