(23-02-2015, 07:26 PM)Xenos a écrit : • Une manipulation DOM possible (exemple: XPath)
• Une coloration syntaxique possible
• Une séparation des espaces de nom (pour mélanger des langages)
• Un traitement par XSL (oui, j'insiste lourdement :p mais je serai curieux de comparer les perfs d'un template XSL processé par libXSL natif, face à un template {{...}} processé en PHP)
Mouais, autant si on a un vrai besoin de performances ça me parle (même si en attendant je prefère un truc lent qui ne m'oblige pas à taper ... ça), autant pour le reste ça me parle pas vraiment :
La manipulation du DOM, vu qu'on créée de toute façon le rendu, on peut s'en passer : pourquoi parser les templates ? Si tu lis le DOM de tes templates pour en lire de l'information, c'est qu'il y a un problème d'architecture amha.
La coloration existe pour twig et blade, pour parler de ceux que je connais.
Pour afficher
{{exemple}}
sur blade c'est @{{exemple}}
, sur twig il faut l'entourer :Code :
{% verbatim %}
...
{% endverbatim %}
Pas terrible. Mais généralement ce sera plus simple d'appeler tes templates javascript depuis ceux en PHP en ne les faisant pas parser.