Il est maintenant habituel de voir les développeurs PHP concevoir leurs applications en suivant l'architecture Modèle Vue Contrôleur (ou M.V.C.), qui est la règle dans le monde Java. Vous faîtes abstraction de vos données et des traitements de fond dans la partie modèle, tandis que les affichages sont gérés par les vues et que le contrôleur joue le chef d'orchestre.

Un framework relativement mûr comme CakePHP impose l'utilisation de ce modèle et même sans cela, c'est une façon de programmer qui devient relativement naturelle. Bien entendu, si vous une malheureuse page à afficher, avec un simple message du style Hello World, se préoccuper du code n'est pas votre priorité.

Pour l'informaticien en herbe, la réflexion survient lorsque sa page de code devient un imbroglio où se mélangent code HTML et appels PHP, sans oublier quelques lignes de Javascript. Il en vient à voir s'il ne pourrait pas séparer la partie présentation, statique, du code de programmation, qui rend sa page dynamique. Cela permet de faciliter la maintenance, notamment de changer le look and feel de ses pages, plus facilement sans toucher à la partie logique.

Le cas extrême mais classique est de passer par la génération de code de données pures comme le XML puis une transformation XSLT pour aboutir à un résultat XHTML et notamment un rendu pour de multiple plateformes : le même flux XML servant de source pour une version imprimable, une version web classique ou une version optimisée pour les i-Phone.

Le processus est cependant coûteux en terme de ressources et il est un peu en porte à faux avec le choix d'une solution PHP, souvent synonyme d'application à moindre coût sur une plateforme de faible puissance. L'option au dessus est certainement le développement d'une solution Java/JSP répartie sur des fermes de machines multicores, en fail over, à coups de serveurs applicatifs dont les prix des licences dépassent les dix mille euros par processeur.

Un choix moins élégant pour l'esprit est d'utiliser un système de templates où se situe tout le code statique d'affichage et de gérer l'insertion des résultats dynamiques via des variables. Dans PHP, les bibliothèques d'outils sont apparues très tôt, avant même le recourt systématique au modèle M.V.C.

Rapidement, les gestionnaires de templates ont dérivé avec l'apparition de pseudo code pour avoir plus de fonctionnalités telle que la gestion de boucles pour afficher toutes les lignes d'un tableau, à partir d'une seule variable, sans que ce soit à gérer dans le code classique PHP. Là, les détracteurs ont été nombreux, en mettant en avant que les systèmes de templates entraîne un coût supplémentaire en calcul et qu'il est complètement absurde d'en utiliser au dessus de PHP, car PHP est déjà un système de templates.

La consommation de ressources est amortie avec le recours aux bibliothèques de cache qui conservent les pages générées et servent rapidement les sauvegardes. La gymnastique du programmeur est de trouver un juste milieu entre une fréquence de rafraîchissement raisonnable, si le contenu évolue au cours du temps, et une minimisation des calculs à faire lorsqu'un visiteur arrive.

C'est jouable quand vous avez des pages communes à tout le monde dont l'information est relativement statique. Cela l'est moins si votre page est personnalisée pour chaque visiteur, avec un contenu qui évolue vite au cours du temps. La page en cache est toujours obsolète et vous devez la régénérer à chaque visite et en plus vous consommez de l'espace disque et vous traitez du code supplémentaire pour des prunes.

CakePHP ne donne aucune contrainte quant à l'utilisation de templates pour la vue et vous pouvez tout à fait coder cette partie en PHP, tout en vous focalisant sur de la gestion d'affichage. En pratique, ce n'est pas aisé. D'une part à cause du mélange code de présentation, style CSS, Javascript et XHTML avec votre code PHP au milieu, un problème que j'ai déjà mentionné. L'autre travers est la tendance de mettre trop d'intelligence dans le contrôleur et de restreindre la vue à une simple impression, du coup votre contrôleur devient massif.

L'utilisation d'un système de templates comme Smarty introduit un meta langage particulièrement riche, qui vous permet à la fois de séparer la présentation du code et d'insérer juste ce qu'il faut comme intelligence dans votre couche d'affichage. La valeur ajoutée de Smarty est de retranscrire son langage propre sous forme PHP et ces fichiers sont physiquement générés. Vous avez une pseudo compilation. Votre code fait appel aux fichiers PHP sans passer par une interprétation systématique des fichiers templates. Même si le code généré peut comporter quelques lacunes en terme d'optimisation, le gain est appréciable et rejoint les performances d'un codage direct en PHP, avec la clarté et le bon dosage d'intelligence en plus.

A mes yeux, l'autre grande valeur ajoutée de Smarty est sa gestion avancée du cache. La gestion de cache proposée par Smarty est un peu lourdingue pour les cas simples. Des bibliothèques plus pauvres se contentent de photographier les pages et se basent sur leur adresse web pour les retrouver dans leurs indexes. C'est peut être simpliste mais c'est efficace et c'est d'ailleurs ce que je préfère utiliser sur certaines parties du site.

Smarty dévoile surtout sa puissance dans des situations plus élaborées, où vous avez besoin d'avoir une partie dynamique sur votre page tandis que le reste ne bouge pas. C'est le cas par exemple sur notre page d'accueil, où les utilisateurs sont différenciés par l'affichage de leur nom. L'accueil passe par de nombreuses requêtes à la base de données pour être fabriqué et le générer complètement, à chaque visite, met à mal le serveur. D'un autre côté, la page du visiteur A ne peut pas être servie au visiteur B car elle affiche le nom d'utilisateur de A.

Smarty propose une alternative très simple avec l'insertion de tags spécifiques dans les templates pour signaler qu'une partie doit être systématiquement calculée, alors que le reste peut être stocké en mémoire et resservi. Il s'agit cependant d'une fonction avancée et il faut que le module tokenizer soit activé sur votre moteur PHP. Il l'est normalement par défaut.