Smarty - Engin de template
Sortit en janvier 2001, Smarty est devenue un projet stagnant et contenant encore beaucoup de bug. De plus est, Smarty est devenu, aujourd’hui, l’engin de template PHP le plus populaire et le plus utiliser. Mais cela ne devrait pas être le cas. Cet article est pour avertir les développeurs de ne pas utiliser cet engin et utiliser des alternatives qui sont de loin supérieures.
Cette articles est aussi, en partie, une traduction dans mes propres mots du site anglais nosmarty.net
Est-ce que SMARTY est bon pour moi?
Il ne faut pas se fier au nom de l’engin, car SMARTY n’est pas la solution la plus intelligente disponible actuellement. C’est vrai que SMARTY a recu plusieurs mentions année après année. Mais quoi qu’il en soit, la plupart d’entre eux on été écrit par des développeur qui n’était vraisemblablement pas familier avec une architecture multi-tier. Pour ces utilisateurs, le concept de séparation de la logique et de la présentation est un concept innovateur. Mais SMARTY est seulement une façon pour parvenir a faire cette séparation (qui ne fait pas très bien d’ailleurs) et aujourd’hui totalement dépasser par les autres produits existants.
Quelques solutions de rechange plus intelligentes
Il existe plusieurs alternatives à SMARTY.
Personnellement, comme vous avez pu le remarquer sur mon blogue, je suis vendu à Zend Framework. Il fait une très belle job et assez simple a utiliser et intégrer. Consultez la documentation sur Zend_View et Zend_Layout et vous pourrez juger par vous même.
SMARTY a sur son site web une liste des bénéfices (en anglais). Allons voir quelque un de ces bénéfices et descendons-les de leurs piédestaux.
Caching
Voici ce que SMARTY dit (en anglais) :
Smarty provides fine-grained caching features for caching all or parts of a rendered web page, or leaving parts uncached. Programmers can register template functions as cacheable or non-cachable, group cached pages into logical units for easier management, etc.
OK. Alors, jetons un oeil au système de cache de Smarty. Pour activer le cache, vous allez écrire quelque chose comme :
$smarty = new Smarty(); $smarty->caching = 1;
Cela configure le cache avec un temps de vie de 3600 secondes (1 heure). Comment faire alors si vous voulez utiliser un TTL, disons, de 30 minutes? Vous allez écrire :
$smarty = new Smarty(); $smarty->caching = 2; $smarty->cache_lifetime = 1800;
Oh, évidement, $smarty->caching = 2;. Quoi d’autre cela aurait pu être? Bien… une constante aux lieux d’un nombre magique aurait été, bien mieux je crois. Mais attendez, pourquoi le TTL dépend qu’un nombre magique soit configuré pour pouvoir s’appliquer? Si caching est accessible directement par une propriété publique de Smarty, ne devrait-il pas être au moins un boulean, soit vrai ou faux?
Il y a plusieurs casse-têtes comme cela un peu partout dans Smarty. Le fait que ce soit non intuitif à un impacte réelle sur notre usage au jour le jour de Smarty, car nous sommes forcés de nous référer à la documentation encore et encore pour des choses souvent très courantes.
La syntaxe n’est pas le seul problème. Utiliser le cache de Smarty dans un environnement avec plusieurs serveurs peut s’avérer un vrai mal de tête, car les fichiers générés ne peuvent pas être réutilisés par un autre serveur sauf s’il utilise des systèmes de fichier en cluster comme GFS ou OCFS.
Configuration
Jetons un oeil à la configuration (en anglais) :
Smarty can assign variables pulled from configuration files. Template designers can maintain values common to several templates in one location without intervention from the programmer, and config variables can easily be shared between the programming and presentation portions of the application.
Smarty vous permet de sauvegarder vos fichiers de configuration en format INI et ensuite les charger. Il y a déja une fonction php pour cela. Elle s’appelle parse_ini_file(). Sauf si vous êtes résistant a utiliser php dans vos template de vue, le chargement des configurations dois ce faire dans la partit logique de toute façons. (Incidemment, Smarty n’utilise pas cette fonction, il opte plutôt pour sont propre mécanisme de traitement pour aucune raison apparente).
Sécurité
Et maintenant la sécurité (toujours en anglais):
Templates do not contain PHP code. Therefore, a template designer is not unleashed with the full power of PHP, but only the subset of functionality made available to them from the programmer (application code.)
Ne penser jamais qu’une application est plus sécuritaire simplement parce que sont engin de template assure qu’il sécurise votre application. La seul sécurité que vous pouvez avoir c’est de désactiver le tag {php} et cela entraîne une augmentation énorme de l’inflexibilité qu’aura votre designer de template. Il faudra alors que votre développeur PHP développe de nombreux plug-ins au fur et à mesure que votre designer de template progressera. La plupart des sites qui utilise Smarty avec le tag {php} activé pour éviter d’avoir a faire milles courbettes pour arriver à leur résultat. Donc où est la véritable sécurité dans Smarty?
De toutes façons, aujourd’hui, les trous de sécurité les plus courants ne viennent pas des templates, mais des développeurs paresseux qui ne filtre pas les données entrantes. Si vous avez un trou de sécurité dans un template, je vous conseille de changer de développeur! La meilleure sécurité se trouve dans un bon développeur consciencieux!
Facile à utiliser et à maintenir
Smarty dit ceci à propos de sa facilité d’utilisation (encore et toujours en anglais) :
Web page designers are not dealing with PHP code syntax, but instead an easy-to-use templating syntax not much different than plain HTML. The templates are a very close representation of the final output, dramatically shortening the design cycle.
Par le passé, j’ai personnellement beaucoup utilisé Smarty. La syntax est relativement facile et on pouvais bien voir la séparation du html et de la syntax Smarty. J’ai appris Smarty, car j’utilisais le CMS XOOPS. Un système de portail évoluer qui existant sous PHP4. J’ai après PHP avec ce portail. Bien évidemment, ce portail utilisait Smarty comme engin de template. Cela m’aidait beaucoup dans le développement de nouveau thème pour ce CMS. Enfin, c’est ce que je croyais!
Mais regardons un peu cette syntaxe.
{$foo}
Ce n’est pas vraiment plus compliquer à utiliser et à maintenir que :
<?= $foo ?>
Bon ok. 3 caractères de plus. Mais comparer à toute la compilation qu’il va faire pour traiter {$foo}, c’est pas sa qui devrais vous faire reculer.
Et Smarty demontre qu’il n’est pas facile a maintenir en comparaisons :
<?= foo ?>
Va afficher « foo », vous donnant un indice que vous vouliez imprimer une variable, mais qu’il vous manque un signe de $ et puis
{foo}
Qui va afficher… rien! Vous laissant complètement dans ignorance que vous avez oublié le signe $.
Et quand vous assignez une variables :
{assign var=”foo” value=”bar”}
c’est certainement plus facile a lire et plus intuitif que
<?php $foo = ‘bar’; ?>
Bien sûr ce ne sont que des exemples très basiques. Le vrai test de syntaxe entre PHP et Smarty c’est avec une approche plus complexe par exemple :
{capture assign=”foo”}{my_helper var1=”bar” var2=”qux”}{/capture}
qui est un peu trop bizarre pour les nouveaux utilisateurs comparés a quelque chose comme dans une application MVC :
<?php $foo = $this->myHelper(‘bar’, ‘qux’); ?>
Qui va être beaucoup plus intuitif et facile a comprendre.
« Variable Modifiers »
The content of assigned variables can easily be adjusted at display-time with modifiers, such as displaying in all upper-case, html-escaped, formatting dates, truncating text blocks, adding spaces between characters, etc. Again, this is accomplished with no intervention from the programmer.
L’idée des « variable modifiers » est d’aider le monteur HTML a ne pas avoir a recourir au programmeur php pour faire ses templates. Smarty vient avec 22 de ces modifiés, mais le programmeur devra en créer plusieurs autres pour atteindre cet objectif. Et il y aura toujours de nouvelle demande, encore et encore, et au final, vous activerez {php} car ce sera moins compliqué.
Fonction de template, Filtre, Plugins et Add-ons
Many functions are available to the template designer to handle tasks such as generating HTML code segments (dropdowns, tables, pop-ups, etc.), displaying content from other templates in-line, looping over arrays of content, formatting text for e-mail output, cycling though colors, etc.
The programmer has complete control of template output and compiled template content with pre-filters, post-filters and output-filters.
Almost every aspect of Smarty is controlled through the use of plugins. They are generally as easy as dropping them into the plugin directory and then mentioning them in the template or using them in the application code. Many user-community contributions are also available. (See the plugins section of the forum and wiki.)
Many user-community contributed Add-ons are available such as Pagination, Form Validation, Drop Down Menus, Calander Date Pickers, etc. These tools help speed up the development cycle, there is no need to re-invent the wheel or debug code that is already stable and ready for deployment. (see the Add-ons section of the forum and wiki.)
Smarty a plusieurs noms pour ses aides de vue. Les aides de vue sont très pratiques, mais il existe des aides de vue bien meilleure que celle de Smarty avec un plus grand lot de fonctionnalité. La vérité c’est que les aides de vue par défaut de Smarty font le minimum pour aider le programmeur et plusieurs de ces addons contienne du code qui non pas leur place dans un engin de template. C’est le résultat d’une mauvaise séparation des logiques.
Ressources
Templates can be pulled from any number of sources by creating new resource handlers, then using them in the templates.
Mode de debug
Smarty dit ceci à propos de sont mode de débogage :
Smarty comes with a built-in debugging console so the template designer can see all of the assigned variables and the programmer can investigate template rendering speeds.
C’est de loin une interface à la Firebug. C’est simplement un dump de variable de 200 lignes et plus très difficile à suivre.
Compilation
Smarty compiles templates into PHP code behind the scenes, eliminating run-time parsing of templates.
Smarty va compiler ses templates en code PHP. Ça devrait vous donner une bonne piste! Vraiment!
Performence
Smarty performs extremely well, despite its vast feature set. Most of Smarty’s capabilities lie in plugins that are loaded on-demand. Smarty comes with numerous presentation tools, minimizing your application code and resulting in quicker, less error-prone application development/deployment. Smarty templates get compiled to PHP files internally (once), eliminating costly template file scans and leveraging the speed of PHP op-code accelerators.
Rien en PHP ne pourrait être plus rapide que PHP lui même! PHP est déjà lui même un engin de template à la base.
Conclusion
Pour conclure, si Smarty n’est pas le bon outil pour faire la job, quel autre outil puis-je utiliser? Il y a plusieurs alternatives qui font exactement ce que Smarty fait, mais encore mieux! Mon framework favori pour le moment est Zend Framework. Il supporte plusieurs types de cache, de configuration, de filtre, d’aide de vue et plus encore. Il est écrit en PHP5 et utilise PHP5 tout simplement pour ses templates. Il y aussi d’autre alternative que vous pourrez facilement trouver en faisant une petite recherche sur Google.
Mais s’il vous plait… n’utiliserplus SMARTY!
Tags: PHP, smarty, solution intelligente, template engine, zend, Zend Framework, zend_layout, Zend_View
No related posts.
Tags: PHP, smarty, solution intelligente, template engine, zend, Zend Framework, zend_layout, Zend_View
Je ne suis pas tout à fait d’accord avec cette vision.
En gros pour moi le seul intérêt de smarty est d’avoir une syntaxe très lisible qui s’intègre bien dans un code HTML. A l’usage et après avoir essayé des templates php sur un gros projet, je vais revenir à smarty.
Le système de plugins de smarty avec les trois types de plugins (soit un pipe, soit une fonction, soit un bloc avec des balises ouvrantes et fermantes) va aussi dans le sens de la clarté de la syntaxe.
Bref au delà de toute considération théorique, je trouve que les fichiers de templates smarty sont tellement plus lisibles que je pense que smarty a de beaux jours devant lui…
A+, Philippe
J’ai utilisé Smarty depuis longtemps mais depuis que j’utilise Zend_View, c’est encore plus simple. Que peut-il y avoir de plus simple et clair que du PHP pure comme syntax? Et utiliser Smarty simplement parce que ca à l’air plus clair ne me semble pas une raison valable.
Voici ci-dessous, le layout principale de l’interface d’administration de mon projet PhenixApp. C’est du simple PHP comme syntax et c’est très lisible! Avec la syntax Smarty, ca m’étonnerais que ce sois aussi clair.
Et créer des Views Helpers avec Zend Framework est beaucoup plus rapide et plus efficace avec Zend_View_Helper qu’avec des plugins Smarty. Sans compté que smarty c’est du PHP 4! Et qu’on est rendu a PHP 5.3.
En tous cas c’est mon opinion.
@M4d3L : de façon générale, il n’y a pas une unique bonne pratique de codage, ça dépend pas mal de la sensibilité des codeurs
. Les vues sont rarement le truc le plus complexe d’un site. J’ai tendance à penser que décider d’utiliser un moteur de template ou directement du PHP, c’est assez anecdotique dans les choix architecturaux d’un projet 
@Philippe : je ne dit pas qu’il y a qu’une bonne pratique de codage. Je dis simplement que Smarty est dans le bas fond de la liste. A mon avis le choix d’utiliser Smarty est le plus souvent due a l’inexpérience du programmeur (comme je l’ai été à mes début.) Je croyais que Smarty me facilitais la tache. On parlait déjà beaucoup a la belle époque de Xoops des bons et mauvais cotés de Smarty et ils ont quand même décider d’aller de l’avant avec Smarty. Finalement, ça l’a tuer a petit feu la communauté de Xoops (les meilleurs programmeur on quitter le bateaux et créer leur propre fork de Xoops sans Smarty). Depuis j’ai acquis beaucoup d’expérience sur des projets avec ou sans Smarty et j’ai ouvert les yeux sur ce que Smarty est réellement. Smarty ma beaucoup simplifier la tache quand j’apprenais le PHP. Maintenant que je connais bien le language, Smarty ne m’est plus d’aucune utilité et même que c’est un boulet quand je dois revenir mettre a jour des projets monté avec Smarty.
@M4d3L
merci pour l’inexpérience, ça ne fait que 10 ans que je fais du web et 25 ans que je code
Je pense que je suis au moins autant que toi une tête de mule, j’ai essayé les 2, je me suis fait ma propre opinion, tu n’arriveras pas à me convaincre, je propose d’arrêter le troll ici
@Philippe
désoler. je ne parlais pas nécessairement de toi quand j’ai exprimé mon opinion
D’ailleur j’ai utiliser ton tutoriel sur kitpages pour integrer Smarty avec Zend_View quand j’ai commencé avec Zend Framework. Mais Zend_Framework a bien évoluer depuis et je crois que Zend_View et Zend_Layout sont très bien sans Smarty
Le gros avantage de smarty, c’est qu’a l’époque il était le seul à compiler les templates en php natif. Ce qui donnais de meilleures performances et surtout pouvait être utilisé en doublon avec un cache d’opcode. Maintenant il est clair qu’il commence à être un peu dépassé mais attendons de voire ce que donnera la version 3 actuellement en chantier.
D’apres ce que j’ai vue sa va beaucoup ressembler a Zend_View mais avec un compilateur pour pouvoir utiliser les bracket que tu veux et cacher les templates. Zend Framework fait deja tous sa avec simplicité!
Je suis chef de projet et nous utilisons ZF avec Smarty. Le plus gros avantage de Smarty, c’est que les graphistes peuvent travailler tranquillement sur les templates et les css sans avoir à connaître le langage php. De plus, le fait d’autoriser aux graphistes d’utiliser du code php dans un projet me semble très très limite question sécurité, un graphiste n’est pas un développeur et ne doit pas avoir les privilèges d’accès d’un développeur dans un projet bien organisé. De plus, Smarty peut être intégré facilement à Zend, nous utilisons par exemple très facilement et sans aucun problème les helpers du Zend avec Smarty. Et Smarty est facilement extensible tout simplement en assignant des objets sous forme d’api, sans besoin de créer des plugins ou d’autoriser la balise {php}. Je pense donc tout comme Philippe que Smarty a encore de beaux jours devant lui…qui plus est la version 3 sera 100% php5
Comme j’ai mentionner dans mon articles, j’ai longtemps utilisé Smarty avec Zend Framework. J’ai encore plusieurs site qui roule avec Smarty comme engin de template.
Mais a quoi sert d’apprendre un autre language au graphiste. Il n’est pas plus long de leur montrer la base de la syntax php pour qu’il puisse faire ce qu’ils veullent autant qu’avec les balises Smarty. Je ne crois pas que ce sois plus risqué coté securité de laisser le graphiste faire du PHP puisque dans la vue, il ne devrais pas y avoir d’accès a la BD sauf dans les helpers qui devrais normalement etre coder par le developpeur php. Le resultat final devra de toutes façon être valider par un developpeur PHP avant la mise en production.
De plus, avec Zend_View, il ont normalement accès strictement au variable qu’il ont besoin d’acceder pour la vue qu’ils sont en train de créer. Et vos graphiste un peu plus connaissant de php vont avoir beaucoup plus de liberté pour créer leur design sans avoir a faire appelle au developpeur php pour qu’il ajoute d’autre plugin ou autre api.
Sous php, c’était nécessaire. Sous PHP5, ce ne l’est plus.
Je suis d’accord sur le fait que le graphiste ne dois pas avoir les accès développeur. Mais il n’est pas nécessaire de leur donner les accès développeurs au graphiste pour qu’il puisse faire les vue avec du PHP. Le graphiste devrait avoir accès qu’au dossier de vue et non au projet entier.
Avec des exemples et des templates déjà existants, l’apprentissage de Smarty se fait très rapidement et nos graphistes sont formés en moins de deux heures. Je persiste à dire qu’autoriser un graphiste à coder du php n’est pas sa vocation dans un projet. Autoriser un graphiste à coder du php décuple les risques de sécurité. Et même si les dossiers sont protégés, je peux vous faire tomber votre application avec une seule ligne de code. Tandis qu’avec Smarty, les contours sont bien définis car justement Smarty est une interface faite pour les graphistes. Maintenant, libre à vous de mener vos projets d’une autre manière.
Je suis d’accord seulement si vous développer vos projets directement live sans environnement de developpement. Smarty est capable d’ignorer les erreur que les graphiste peuvent faire dans les templates. Sinon je ne vois vraiment pas ou sont les risques de sécurité si tous est fait dans un environnement de developpement (avec utilisation de gestionnaire de source ou backup régulier du projet) avant d’être mis en ligne. Et faire du debug avec Smarty est bien moin évidant car justement a moin d’une erreur fatal, il ne dit pas qu’il y a une erreur. En PHP directement, s’il y a une erreur, le graphiste peut le voir aussitot.
Je ne dit pas que Smarty n’est pas bon. Je dis seulement qu’aujourd’hui, il y a de meilleur méthode et je veux vous amener a réfléchir sur le choix de votre engin de template pour vos futurs projets. Je n’irai pas réecrire tous mes sites déjà faite pour retirer Smarty. Mais je ne l’envisagerai plus dans mes futures projets sauf, si bien sur, mon employeur veut toujours utiliser Smarty. Mais libre a vous de l’utilisé ou non.
Bon ben comme l’article dit d’utiliser une alertnative putôt que de laisser tomber les moteurs de templates, c’est l’occasion de voius parler de TinyButSTrong.
TBS est un moteur mature, stable, rapide, et déjà très utilisé. Il est vraiment simple à mettre en place (un seul fichier) et c’est le seul jusqu’à aujourd’hui qui permette de faire des modèles avec Dreamweaver ou tout autre éditeur visuel.
http://www.tinybutstrong.com/fr
TinyButSTrong semble être encore PHP4 si j’en crois ce qui est marquer sur le site. Si vous travailler avec PHP5, il est préférable d’utiliser des librairies écrite pour PHP5.
Surtout pour ce qui est de la version 5.3 de PHP qui vien d’être releaser qui a de plus en plus de différence avec PHP4.
je pense qu’il faut savoir utiliser un moteur de template, comprendre son fonctionnement, et de bien distinguer exécution et affichage.
Certes sans cette vision, il est dur de voir smarty comme un vrai outil.
Mais entendre dire, qu’il faut choisir zend au lieu de smarty, ca me fait bien rire, comparer un gestionnaire de template contre un framework.
Comparons ce qui est comparable.
Smarty est un trés bon produit, quand l’on comprend ce qui peut apporter vraiment.
Ca fait 4 ans que je développe sur smarty, j’ai jamais mis un balise {php} dedans.
Je suis pas d’accords avec toms, smarty s’est inutile, sa prends beaucoup de place en mémoire, c’est lourd à mettre en place et à débugger.
Zend_View est un moteur de template de Zend. Tu n’es pas obligé d’utiliser le Framework au complet pour utiliser Zend_View. Zend_View viens retirer la couche de compilation que tu as besoin de faire pour compiler les tags spécifique de smarty. Quoi de mieux que d’écrire du pur PHP dans le template? C’est beaucoup plus convivial. Et de plus, programmer les helpers (fonction ou modifier sur smarty) est beaucoup plus conviviale avec Zend_View. Je comprends très bien la notion de diviser l’exécution et l’affichage.
Si vous en doutez, essayez Zend_View quelque temps. Et vous me direz après ce que vous pensez de Smarty!
A l’époque j’ai voulu utiliser Smarty, et via le forum de Smarty je suis tombé sur cet article très intéressant:
http://www.massassi.com/php/ar.....e_engines/
J’ai complètement abandonné l’idée de Smarty au profit de cette classe template en PHP pur.
Maintenant j’utilise CakePHP qui a aussi un système de templates en PHP pur.