"Comment rendre mes scripts PHP indépendants de la présentation ?". Voici sans doute la question la plus posée sur la mailing list PHP. Alors que PHP est étiqueté "langage de script pour HTML", on se rend vite compte, après quelques projets qui mélangent sans complexe HTML et PHP, que la séparation entre la forme et le contenu, c'est bien [TM]. De plus, dans de nombreuses entreprises les rôles du designer et du programmeur sont distincts. La solution template coule donc de source.

Dans notre entreprise par exemple, le développement d'une application se fait de la manière suivante : une fois le cahier des charges écrit, le designer réalise une maquette, et donne ses interfaces au programmeur. Le programmeur implémente les fonctionnalités applicatives et utilise les maquettes pour faire des squelettes de templates. Le projet est alors passé au designer HTML/responsable de la mise en page qui amène les templates jusqu'au faîte de leur gloire. Il est possible que le projet fasse une fois ou deux des allers/retours entre la programmation et la présentation. En conséquence, il est important de disposer d'un bon système de template. Les programmeurs ne veulent pas avoir à faire au HTML, et ne veulent pas non plus que les designers HTML bidouillent le code PHP. Les designers ont besoin d'outils comme des fichiers de configuration, des blocs dynamiques et d'autres solutions pour répondre à des problématiques d'interface, mais ne veulent pas nécessairement avoir à faire à toutes les subtilités de la programmation PHP.

Un rapide tour d'horizon des solutions type template aujourd'hui et l'on s'aperçoit que la plupart d'entre elles n'offrent que des moyens rudimentaires pour substituer des variables dans des templates, ainsi que des fonctionnalités limitées de blocs dynamiques. Cependant nous avons besoin d'un peu plus. Nous ne voulons pas que les programmeurs s'occupent de la présentation HTML du TOUT, mais celà est pratiquement inévitable. Par exemple, si un designer veut des couleurs d'arrière plan différentes pour alterner entre différents blocs dynamiques, il est nécessaire que ce dernier travaille avec le programmeur. Nous avons aussi besoin que les designers soient capables de travailler avec leurs propres fichiers de configuration pour y récupérer des variables, exploitables dans leurs templates. Et la liste est longue.

Fin 1999, nous avons commencé à écrire une spécification pour un moteur de template. Une fois la spécification terminée, nous avons commencé à travailler sur un moteur de template écrit en C qui pourrait, avec un peu de chance, être inclus à PHP. Non seulement nous avons rencontré des problèmes techniques complexes, mais nous avons participés à de nombreux débats sur ce que devait et ce que ne devait pas faire un moteur de template. De cette expérience nous avons décidé qu'un moteur de template se devait d'être écrit sous la forme d'une classe PHP, afin que quiconque puisse l'utiliser à sa convenance. Nous avons donc réalisé un moteur de template qui se contentait de faire celà, et SmartTemplate™ a vu le jour (note : cette classe n'a jamais été soumise au public). C'était une classe qui faisait pratiquement tout ce que nous voulions : substitution de variables, inclusion d'autres templates, intégration avec des fichiers de configuration, intégration de code PHP, instruction 'if' basique et une gestion plus robuste des blocks dynamiques imbriqués. Elle faisait tout celà avec des expressions rationnelles et le code se révéla, comment dire, impénétrable. De plus, elle était relativement lente pour les grosses applications à cause de l'analyse et du travail sur les expressions rationnelles qu'elle devait faire à chaque exécution. Le plus gros problème du point de vue du programmeur était tout le travail nécessaire en amont, dans le script PHP, pour configurer et exécuter les templates, et les blocs dynamiques. Comment rendre tout ceci plus simple ?

Puis vint la vision de ce que devait devenir Smarty. Nous savons combien le code PHP peut être rapide sans le coût d'analyse des templates. Nous savons aussi combien fastidieux et décourageant peut paraître le langage pour le designer moyen, et que celà peut être remplacé par une syntaxe spécifique, beaucoup plus simple. Et si nous combinions les deux forces ? Ainsi, Smarty était né...:-)