J’ai découvert Smarty il y a environ 5 ans. J’ai alors été rapidement séduit par ce que ce moteur de template permet de faire. Mais depuis, j’ai déchanté.
J’ai utilisé Smarty dans le développement d’un site basé sur une architecture MVC. Si Smarty offre des fonctionnalités non négligeables (comme le cache qu’il gère à la perfection), le pseudo-langage utilisé pour la mise en forme, loin d’être véritablement un atout, se révèle être finalement un handicap dans certains cas.
Cherchant à toujours utiliser ce qui se fait de mieux en matière de développement objet en PHP, je n’utilise plus que PDO pour accéder à mes bases de données. PDO fournit des résultats qui sont des objets PDOStatement, qui implémentent l’interface Traversable. Ce qui signifie, en langage clair, qu’un résultat de requête avec PDO peut être utilisé directement dans une boucle foreach, au même titre qu’un Itérateur. De ce fait, je ne boucle plus dans mon contrôleur sur les données obtenues : je passe l’objet PDOStatement à ma vue qui se charge de la mise en forme. Et c’est là que Smarty montre ses faiblesses : le pseudo-langage de Smarty permet certes de modifier la présentation des données, mais il ne permet pas de faire plus. Vous me ferez certainement remarquer que c’est bien là son but et qu’il n’est pas voué à autre chose. Par ailleurs, on n’est pas censé, dans la vue, faire autre chose que de la présentation de données. Certes. Cependant, si ma vue était en pur PHP, je pourrais décider de l’affichage de telle icone ou telle autre en fonction de l’existance d’un fichier, dont le nom est retourné par mon objet PDOStatement. Avec Smarty, je ne peux pas.
L’alternative serait d’itérer sur le résultat PDOStatement dans le contrôleur pour traiter cette information, puis passer le tout (sous une forme que je ne détermine pas) à la vue. Mais cela me paraît absurde à plus d’un titre : non seulement on itère sur le résultat dans le contrôleur alors que les Itérateurs permettent justement de se passer de ça, mais en plus on effectue un traitement, dans le contrôleur, duquel dépend une présentation différente dans la vue. Et je ne suis pas d’accord avec cette manière de faire.
Ma conclusion est que je n’utiliserai plus Smarty comme gestionnaire de vues : il n’offre pas grand chose de plus, en terme de traitement des informations que du PHP pur. Au contraire, il rajoute une couche supplémentaire et nécessite une syntaxe bien spécifique qui, bien que proche de PHP, n’en reste pas moins différente. Pour ce qui est du cache, il n’est pas bien difficile de mettre au point une classe qui gère ça, de manière indépendante.
Comments (5)
Totalement d’accord, ce sont les mêmes points qui font que je n’utilise pas Smarty, et jamais utilise hormis sur des projets deja existants.
Pourquoi utiliser un langage spécifique pour les vues ? Php est fait pour traiter du texte, et il est aise de créer (ou de réutiliser) un gestionnaire de templates ou de cache.
Personnellement, j’ai utilisé Smarty de mon propre chef avant de structurer mes projets selon le motif de conception MVC. Mais avec le temps, je réalise vraiment les lacunes d’un tel moteur de templates.
A vrai dire, aujourd’hui, j’ai du mal à trouver des arguments en faveur de smarty (rapide : oui, ben du PHP pur aussi, du cache : oui, ben ça s’implémente facilement, langage souple : pas autant que du PHP pur, etc).
Il reste un argument: certains integrateurs ne connaissent pas php mais smarty oui, c’était le cas sur le projet ou j’ai bosse avec.
Un deuxième, c’est que ça force la couche présentation a ne faire aucun traitement. Dans ce sens la je trouve XSLT interressant
Si un intégrateur est capable d’apprendre le pseudo-langage de Smarty, il doit alors être capable d’apprendre le minimum de PHP permettant de faire la même chose (parce que {foreach from=$var item=item} c’est pas forcément plus intuitif que foreach ($var as $item) ). Quant à l’instruction echo elle n’est pas bien difficile à appréhender.
Pour ce qui est de XSLT, pour ma part, j’ai trouvé ça trop lourd à mettre en place quand je m’y étais intéressé (il y a 2 ans). Je n’ai donc pas cherché plus loin, même si l’idée est effectivement intéressante.
Reste que je me demande bien comment gérer mon problème sus-mentionné : si j’ai un fichier présent sur le disque, je l’affiche (par exemple un logo dans une liste d’entreprises), sinon, j’affiche une image par défaut. Le nom m’est fourni par le modèle (typiquement il est fonction de l’id de l’entreprise), mais le fichier doit être présent sur le disque… Or, le contrôleur ne gère pas ça (puisque j’itère directement dans la vue sur l’objet PDOStatement) et ce n’est pas non plus le rôle de la vue… Faudrait une classe spécifique, mais qui serait alors inutilisable dans Smarty, à moins d’écrire un plugin spécifique… ? Je reste perplexe…
Merci beaucoup pour cet éclairage très intéressant!