Cependant, si l’on part du principe que les templates sont utiles lorsque plusieurs personnes travaillent sur un même projet, le manque de standardisation de ces moteurs est très gênante : chacun utilise le moteur qui lui plait le plus, et il n’est pas évident d’en trouver un que tout le monde puisse prendre en main facilement…

Le « top » serait de pouvoir n’utiliser uniquement que quelques fonctions PHP (les conditions, boucles, affectations), mais pas toutes les autres (mysql_* par exemple)

Raison de plus pour utiliser un bon échappement à l’affichage plutôt qu’une hâche à la saisie

Tu peut potentiellement te prendre beaucoup d’attaque de type XSS même en échappant les caractères à la sortie.

Il faut absolument faire les 2 : c’est la base du Web quand même, je dirais même qu’il faut surtout la hache à la saisie. Ensuite, le langage autorisé est le HTML dans les commentaires (Je t’accorde l’erreur d’ergonomie qui ne donne pas cette information, je la corrigerais).

Ensuite, pour les accolades, il existe la syntaxe avec les « : » qui est faite pour cela.

Par contre, l’argument sur la forte isolation me fait plutôt rire, il ne faut pas confondre la vue d’un modèle MVC et un moteur de template. L’isolation forte entre la vue et le reste est souvent nécessaire comme tu le dit, mais le langage de template n’apporte absolument rien à ce niveau.

Après, tu dit que le template n’a strictement accès qu’aux données qu’on lui fourni, et absolument rien d’autre, si tu savais le nombre de fois où j’ai vu des contournements par l’intermédiaire d’un proxy ajax pour récupérer des donnés pour contourner cette limitation contre-productive, ça fait simplement froid dans le dos.

Dans un exemple qui m’a particulièrement marqués, l’intégrateur avait besoin d’une liste d’utilisateurs en fonction de certains paramètres, il avait besoin de leur nom, de leur email et de leur numéro de compte client, il attendait le développement de la fonctionnalité qui ne venait pas. Alors, il a décidé de passer par un proxy Ajax pour gagner du temps. Il indique clairement la raison dans le commentaire du code. Je cite « Le temps que quelqu’un me implémente l’opérateur que j’ai besoin et qu’il le commit, je le site sera déjà en ligne ».

De ce point de vue, je rejoint Benjamin Franklin en disant : « Celui qui est prêt à sacrifier un peu de sa liberté pour plus de sécurité ne mérite ni l’une ni l’autre, et finit par perdre les deux. »

pour ma part j’utilise un moteur de template maison pour ces raisons :
- simplification du code. Par défaut un {name} correspond à un name); ?>. C’est pour moi un raccourci important, qui évite bien des oublis coté code.
Toutefois avec cet échappement automatique il n’y a pas l’impact « wash / dewash / rewash » que vous indiquez : si je mets {url:name} le htmlspecialchars sera simplement remplacé (à la « compilation ») par un rawurlencode.
En effet on reprend l’utilisation des « modifiers », un peu comme on peut le trouver dans le moteur de template Flexy.

• bonne intégration HTML. J’aime ce genre de syntaxe : {userName}, qui m’évite d’avoir à placer l’accolade fermante de mes ifs, foreach ou autres blocs. Le XHTML est balisé, donc on utilise avant tout les balises déjà présentes.

• forte isolation. Mon but à l’origine était de permettre aux membres d’utiliser leurs propres templates, sans compromettre la sécurité du site (pour une plateforme de blog mutualisée par exemple). Ainsi le template n’a strictement accès qu’aux données qu’on lui fourni, et absolument rien d’autre.

Bien sûr, on parle d’idéal…

Ton nouveau lecteur

Par ailleurs, pour l’échappement des caractères, je ne peut pas être d’accord sur l’auto-échappement, prenons l’exemple simple mais désormais classique de faire un simple lien dans un nouvelle fenêtre accessible. La règle d’échappement n’est pas identique entre le title et le contenu entre la balise, pourtant une partie du texte est identique. Donc avec un « autowash », tu doit « dewasher » pour « rewasher » correctement.

Pour ce qui est de la sandbox, ça donne l’air d’avoir de la sécurité,pourtant il n’en est rien on peut toujours rajouter des balises, des opérateurs qui vont être appeler dans les templates qui feront exécuterons le code PHP que l’on a voulu caché. C’est vraiment de l’illusion de sécurité.

Sinon, la page montre quand même quelque chose d’intéressant, seul le PHP à une coloration syntaxique correcte.

Je ne suis pas trop fan des moteurs de template pour ma part… sachant que PHP est déjà un langage de template (oui je sais, je sors l’argument des anti smarty mais bon, je suis d’accord avec eux).

Secondo, quand je vois sur ezPublish la complexité du langage de template, je déplore de ne pas pouvoir justement coder en PHP… et j’en passe et des meilleurs. PHP est assez simple pour entrer dans un template, suffit de ne pas coder du fonctionnel dans le template et ça reste très très clair.

Tercio, on tombe très souvent sur des cas compliqué avec des langages de templates… le code devient justement vite illisible à cause de ça.

Et enfin, en ce qui concerne le cache, un bon framework doit permettre le paramétrage, utiliser APC (et pas seulement l’activer… non non, mais utiliser l’API cf. http://www.copix.org qui l’utilise parfaitement bien)

Oui, copix permet d’utiliser Smarty… mais je vois de plus en plus de dev arrêter d’utiliser ce truc pour revenir à du template PHP bien fait.

Bref, question de gout, question de logique… chacun son choix: le mien est fait ! ;)

Celui qui est prêt à sacrifier un peu de sa liberté pour plus de sécurité ne mérite ni l’une ni l’autre, et finit par perdre les deux.

Cette citation de Benjamin Franklin résume bien la problématique des langages de templates en PHP.

Par ailleurs, l’effet pervers du langage de templating, c’est qu’il diminue potentiellement le niveau du fameux « développeur moyen », ce qui au final, peut parfois générer un « carnage » tout aussi dévastateur en temps de travail et en performance… Cependant le carnage reste effectivement confiné (sécurité), c’est déjà ca de gagné.

c’est marrant, il y a encore quelques années j’aurais dit comme toi mais je me rend compte que même en environnement pro SSII, le « donc » de ta phrase est très optimiste voire utopiste crois moi :-)
et même avec une couche template avec un langage très restrictif, le développeur moyen arrive toujours à faire n’importe quoi, je te laisse imaginer le carnage sans langage de template…

Je remet pas en cause l’avantage d’avoir une couche dédié au templating, elle est certaine (séparation intégrateur / développeur, sécurité, … ).

Ce qui m’insupporte dans Smarty, eZPublish, eZComponents … pour ne pas les nommer, c’est la syntaxe, la notion de « compilation », l’absence d’outils, … .

[1] http://ezcomponents.org/docs/tutorials/Template#contexts

Pour la gestion du cache, ce n’est pas un avantage, mais pas un inconvénient non plus (sauf si le code généré est mal optimisé). Je précisais juste que comme le cache devient nécessaire tot ou tard, ce n’est pas le templating qui motive le besoin en cache, mais la nature des projets à forte audience.

La dépendance vis à vis des monté de version je suis plutôt d’accord, mais quelque soit le moteur de template (PHP directement, ou ceux écrit en PHP).

Par contre pour la gestion de cache, je ne comprend pas l’avantage. Les langages de templates ne fournissent que du code PHP. On décale juste le problème.
Après les solutions pour mettre en cache du op-code PHP, des résultats sérialisés, des fichiers textes sont multiples (Memcache, APC, XCache, Zend_Platform, … ), et sont relativement simple à mettre en place.