Je vous le dis aujourd’hui, mes amis, bien que, oui bien que nous ayons à faire face aux difficultés d’aujourd’hui et de demain, je fais pourtant un rêve. C’est un rêve profondément ancré dans le rêve américain. Je rêve que dans la prochaine version d’eZ Publish arrive avec une améliorations majeure : des templates en PHP.
Je rêve que l’on puisse utiliser un composant de vue similaire au Zend_View,
qui remplace automatiquement les ‘<?=’ en ‘<?php’, qui sépare complètement
les vues du reste de l’application.
Je rêve d’un langage avec des structures de contrôles adaptés aux templating.
Je rêve d’un monde où les développeurs et les intégrateurs
peuvent partager le même langage.
Je rêve d’un langage rapide à exécuter.
Je rêve d’un node/view/full pour la classe folder qui ressemble à :
<?php /* Folder - Full view */ ?> <div class="content-view-full"> <div class="class-folder"> <h1><?= $node->name->content() ?></h1> <?php if ($node->short_description->is_empty()): ?> <div class="attribute-short"> <?= attribute_view_gui($node->short_description) ?> </div> <?php endif; ?> <?php if ($node->description->is_empty()): ?> <div class="attribute-long"> <?= attribute_view_gui($node->description) ?> </div> <?php endif; ?> <?php $page_limit = ezini('Folder', 'page_limit', 'truffo.ini'); $list_items = $node->subTree(array( 'parent_node_id' => $node->node_id, 'offset' => $view_parameters->offset 'sort_by' => $node->sort_array, 'limit' => $page_limit )); $list_count = $node->subTreeCount(array( 'parent_node_id' => $node->node_id, )); ?> <div class="content-view-children"> <?php foreach ($list_items as $child): ?> <?= node_view_gui($child, 'line') ?> <?php endforeach; ?> </div> <?= template('navigator', array( 'uri' => 'design:navigator/google.tpl', 'page_uri' => $node->url_alias, 'item_count' => $list_count, 'view_parameters' => $view_parameters, 'item_limit' => $page_limit )); ?> </div> </div>
Malheureusement, ce n’est qu’un rêve. En attendant, il est toujours possible de définir un opérateur qui joue le rôle d’adapateur entre le moteur de template
d’eZ Publish et le moteur de template PHP.
{php(array($foo, "bar"), array("three", "four"))}function php($func, $params) { return call_user_func_array($func, $params); }
Moi j’appelle ça remplacer un cauchemar par un autre ;-) PHP est tout sauf un bon langage de template (trop verbeux, insecure, …). Mais bon on va pas refaire le débat.
En revanche pour ton opérateur magique, y’a beaucoup mieux, surtout plus sécurisé (bien qu’un peu vieux) :
http://ezpedia.org/en/project/wrap_operator
Since short_open_tag is on, why not use directly « <?" instead of "<?php" ? It would make typing templates easier
le '| wash()' tu le traites comment? tu transformes le <?= en un appel de wash(…) ?
pour les problèmes de scope des variables (afin qu'un tpl ne puisse pas affecter les variables déjà existantes), on fait comment? On compile tout le template dans une fonction?
avec la 4.3 et sa nouvelle classe pour charger les objets templates, un essai est maintenant possible je crois…
ps: la vraie difference avec les .tpl existants est que dans le language de template tu n’a pas un seul operateur qui te permet de modifier des donnees. Ce n’est que le code des modules qui peut le faire…
@damien no comment, les gouts et les couleurs ca ne discute pas. Personnellement, je trouve PHP beacoup moins verbeux que les templates eZ.
Versus
{if is_set($test)} {if $test|eq('toto')} {* Traitement *} {/if} {/if}Par contre pour l’opérateur wrap_operator merci du lien, un système de limitation via des settings pourquoi pas mais bon quid des méthodes dynamiques, des closures, … .
De manière générale, croire que l’on limite les risques de sécurités lorsqu’on donne la main pour faire des opérateurs est simplement une hérésie.
@ggeek 1 non surtout pas de short_open_tag, je parler d’un système à la Zend_View, qui réécrit à la volée les < ?= en
@ggeek 2 L’échappement des données peut être traitée en amont dans le composant de vue, dans mon exemple, une méthode comme content() peut très bien le prendre en charge, voir directement dans la méthode __toString() de la classe PHP sous-jacente.
@ggeek 3 Utiliser PHP comme langage de template n’a jamais voulu dire être totalement débile, bien sûr qu’un composant de vue doit être dans une sandbox.
@ggeek 4 Je n’ai pas vu passer cette fonctionnalité si tu as plus d’info dessus, je suis preneur.
ton exemple est légèrement biaisée puisque tu n’écris pas la même chose dans les deux cas, le tpl serait plutôt :
{if is_set( $test )|and( $test|eq( ‘toto’ ) )}
{* traitement *}
{/if}
je vais pas aller jusqu’à compter les caractères utiles mais bon…
« De manière générale, croire que l’on limite les risques de sécurités lorsqu’on donne la main pour faire des opérateurs est simplement une hérésie. »
Pas plus, pas moins qu’en utilisant PHP mais le gain de sécurité n’est pas là avec un langage de template ! Au niveau templating, la sécurité c’est principalement comme le fait remarquer gggeek en échappant les données pour éviter les XSS (le wash en ez template, automatiquement dans bcp de langages de template « modernes »). la solution que tu proposes est pas terrible car l’échappement dépend du contexte. si tu génères du HTML ce ne sera pas le même que si tu veux générer un mail en texte brut ou un CSV par exemple. Donc ça veut dire que ton ->content() doit aller chercher le contexte dans lequel il est utilisé mais bon personnellement j’aime pas trop les méthodes qui renvoient des choses différentes en fonction de la phase de la lune. Autre solution, faire comme content() par autre chose ou en lui ajoutant un paramètre pour lui dire comment échapper mais du coup il te faudra « parser » un peu ton PHP… bref tu réinventes un langage de template :-) D’ailleurs dans Zend_View, pour échapper les données proprement, il faut faire un $this->escape($myData) [1], niveau concision face à |wash ou un truc qui échappe par défaut [2] on repassera…
« Par contre pour l’opérateur wrap_operator merci du lien, un système de limitation via des settings pourquoi pas mais bon quid des méthodes dynamiques, des closures, … . »
il est toujours bon d’autoriser explicitement ce à quoi on a le droit sur les aspects sensibles (pouvoir appeler n’importe quelle fonction/méthode là on ne devrait pas EST sensible), c’est plutôt reconnu comme principe en informatique, c’est le principe de la configuration wrap_operator et c’est une excellente chose ça permet de limiter d’éventuels problèmes sur des templates mal écrits. Franchement je serais curieux de voir les templates dans lesquels tu as besoin de closures ou de méthodes dynamiques et surtout j’espère ne jamais avoir à les maintenir… Un template c’est sensé être simple quelques condition ou boucles, des inclusions d’autres templates et quelques affichages de données dans du HTML puisque tout le boulot compliqué de trouver les bonnes données, de les préparer, trier, … a été fait avant (contrôleur/model en MVC, module/vue PHP ou fonction fetch/opérateur dans eZ Publish). Bref si ton template est compliqué, c’est probablement qu’il y a un soucis de conception quelque part…
« @ggeek 4 Je n’ai pas vu passer cette fonctionnalité si tu as plus d’info dessus, je suis preneur. »
En overridant la classe eZTemplate (grace au mécanisme d’autoload), tu dois pouvoir implémenter ton propre moteur de template mais le boulot de réécrire tous les .tpl en autre chose est assez… énorme.
[1] http://framework.zend.com/manual/en/zend.view.scripts.html
[2] http://ezcomponents.org/docs/tutorials/Template#contexts
Sur l’exemple choisi, justement il est choisi parce qu’il introduit une différence très intéressante, et je suis content de voir que l’un des plus grands spécialistes d’eZ Publish fait la même erreur que moi. Dans le premier cas, le cas du template PHP la deuxième condition n’est pas évaluée si le premier test est faux dans le template eZ la deuxième condition est évaluée dans tous les cas. Voila le genre d’effet de bord qui font perdre un temps incroyable avec un moteur de template.
Pour le deuxième point, on parle exactement de la même chose que l’envoi de message passe par un opérateur via « | » ou par un appel de méthode, c’est du pareil au même. Quid d’un ->content(‘email’) ou ->content(‘csv’).
Pour le troisième point, sur le fond, je suis entièrement d’accord, cependant, cette restriction n’a de sens que si l’on interdit également les opérateurs personnalisés. As tu une solution pour interdire cela ?
Par ailleurs, un système de templating basé sur les closures est parfois très intéressants. Le système des builders proposées par Groovy est très intéressants dès lors que le formatage final doit être respecter de la manière la plus stricte.
Faire correspondre erreur de compilation/interprétation est dans ce cas précis un apport intéressant.
Enfin, je voulais plutôt parler des attributs dynamique (méthode __get()) au lieu des méthodes dynamiques qui devenu chose courantes en PHP.
Damned, ZE topic troll. Tu étais en manque de commentaires, truffo, avoue ! :)
Déjà effectivement, le rendu on aime ou on aime pas, c’est une question de goûts. Perso je n’aime pas, mais je comprends qu’on puisse aimer. Même Rasmus aime ça, c’est dire ! Personne n’est parfait.
De mon côté, ayant utilisé des templates depuis mathusalem (plus ou moins 1 an), j’ai du mal à m’en passer, j’avoue. Je trouve cette séparation supplémentaire vraiment utile, surtout par la couche d’abstraction qu’elle apporte. Par contre, j’avoue que eZTemplate se fait vieux… on envisage vraiment l’euthanasie, mais c’est loin d’être aussi simple. Sache cependant que l’intégration de ezcTemplate est censée se faire de concert avec des possibilités plus simples d’utiliser PHP pour du templating.
Le débat sur la syntaxe et ses limites est intéressant, par contre. On a effectivement une belle liste de point à adresser (la syntaxe persistent object, qui devrait faciliter au max les interrogations de propriétés, effectivement via __get, l’échappement, heureusement géré via un contexte dans ezcTemplate, les opérateurs…). Pour ce qui est de limiter les fonctions auxquelles on a accès, cela passera forcément par une phase de compilation, ce qui est un comble pour un template en PHP. On ne peut clairement pas laisser accès à tout et n’importe quoi depuis un template, quand on voit déjà la merde que l’on arrive à voir avec un langage restrictif.
Enfin, sur le & qui exécute les deux tests, ça s’appelle un bug, pas une fonctionnalité ;)
Bon, ben moi j’aime bien les trolls, alors je vais ajouter mon avis tranché, en référence à un des grands comiques français :
Les templates en PHP, je ne suis ni pour, ni contre! Bien au contraire !
Vous pourriez venir troller sur http://share.ez.no sur ce sujet, je pense qu’on pourrait facilement battre le record du nombre de replies sur un forum_topic :) Avis anx amateurs de records.
@bertrand D Non, c’est juste un cri du coeur. J’en ai marre de ne pas pouvoir utiliser mon IDE, j’en marre de passer la quart de mon temps à me battre avec ce langage.
Entre les bugs et les features, comment deviner qui relève du bugs, vu les bizarrerie du langage (espace après le nom des fonctions qui fait planter, …).
Pour avoir essayer ezcTemplate, oui il y a de l’amélioration c’est certain, mais bon toujours pas de coloration syntaxique, d’auto-complétion, d’intelligence de code, … dans les IDE gratuits du marché. Imposer un langage nécessite quelque part de fournir les outils adéquats pour son exploitation.
Parce qu’en attendant l’intégrateur c’est moi, et on me demande faucher un champ avec une faux en me disant « la moissonneuse-batteuse c’est trop dangereux, tu sais y a des gens qui n’ont pas le permis ».
mauvais IDE => changer d’IDE. Eclipse a la coloration syntaxique pour les templates eZ, vim aussi. Pour les autres, ils ont en principe un plugin pour Smarty dont la syntaxe est très proche. OK c’est pas parfait mais pas un cauchemar non plus.
« Pour le troisième point, sur le fond, je suis entièrement d’accord, cependant, cette restriction n’a de sens que si l’on interdit également les opérateurs personnalisés. As tu une solution pour interdire cela ? »
oula faut pas tout mélanger. La définition d’opérateur c’est pour le développeur. La limitation à ce qu’on peut appeler via wrap_operator ou équivalent, c’est pour limiter les problèmes sur un template mal écrit par un utilisateur mal intentionné. c’est pas le même publique si je puis dire.
« Entre les bugs et les features, comment deviner qui relève du bugs, vu les bizarrerie du langage (espace après le nom des fonctions qui fait planter, …). »
Tu te doutes bien qu’un opérateur and qui évalue la seconde condition même quand la première est fausse, c’est un bug ? ce n’est pas une question de syntaxe, c’est la première « optimisation » lorsqu’on touche à la logique booléenne ! D’ailleurs le bug est déjà existant dans le tracker : http://issues.ez.no/13075
« Parce qu’en attendant l’intégrateur c’est moi, et on me demande faucher un champ avec une faux en me disant « la moissonneuse-batteuse c’est trop dangereux, tu sais y a des gens qui n’ont pas le permis ». »
tu dis ça parce que tu travailles toujours seul ou uniquement avec des gens compétents (quel chance!) mais ce n’est pas le cas de tout le monde…
ha ha ha ! Le troll dans le troll, j’ai écouté ton conseil « mauvaise IDE changer d’IDE », je n’utilise plus vim de puis la fin des années 80.
Eclipse oui mais le plugin pour ez est tellement limité que j’ai préféré me rabattre sur jedit en attendant qu’il y ai un plugin pour netbeans. PhpEdit est pas mal mais bon j’ai pas windows.
J’ai reprendre ta formule, et je dirait « mauvais intégrateur changer d’intégrateur ».
Mais bonne question quand même, quel éditeur utilisez vous pour éditer ces templates ?
moi: jedit + fichier de coloration maison
Rho comment tu y vas….(en troll) :)
Eclipse + JAC/Smile template plugin. Et ça marche très bien de mon côté !
Allez hop, essai de battre le record de commentaires!
A propos de l’enregistrement de nouveaux opérateurs de template: c’est surement le boulot de 2 gars différents, le templateur et le développeur. Le développeur peut foutre le bordel complet en code php via simple modification à l’autoload ou même par hacking des classes fournies (code source dispo, sauf utilisation encodeurs en general très foireux). Donc impossible de sécuriser au sens stricte quoi que ce soit. Le but ici est, ayant validé les opérateurs et les fonctions de fetch, de pouvoir dire que le site est sécurisé, à la limite peu performant, car le templateur ne peux pas ajouter des failles (voir escape automatique fait par le ezct qui est bcp mieux que le wash).
Mois j’utilise phpedit, mais je recommande ezgeshi aux pauvres qui veulent de la couleur, au moins en lecture et pas dans une ide. L’intégrer
dans bespin est un rêve dans mon tiroir.
Un petit coup de pub en plus, faites un tour par ezsysinfo, il y a maintenant pas mal d’introspection sur les op. de template et autres vues, en live sur le site installé.
Dernier détail, je parle de la fonction eztc::factory qui va initialiser la classe template. Facile donc de mettre en place un nouveau moteur de template, bcp plus dur de réécrire tous les templates existants…
C’est vraiment l’arlesienne, ça fait dix que je suis dans l’informatique, je l’attend toujours le templateur qui ne fait que du HTML. En plus, le métier d’intégrateur a clairement évolué aujourd’hui, il manipule des langages de haut-niveau (javascript, action script), et il est sensible au attaque CSRF et XSS. On parle beaucoup plus maintenant de développeur front que d’intégrateur.
Il faut que je regarde plus en détail le moteur de template eztc, pour faire une idée plus précise du truc. 2 questions cependant, quand sera t’il intégré à eZ (2010 ? 2011 ? 2024 ?).
Ensuite pour la réécriture des templates existants, dire qu’il sont incomplet, inadaptés au Web d’aujourdhui (conformité XHTML Strict voir HTML 5, accessibilité, … ) n’est pas faire injure à eZ Systems. Vu qu’il sont inutilisables en l’état, la suppression des templates présent actuellement serait déja pas mal.
Ensuite, faut’il écrire des templates directement utilisables ne me semble pas vraiment utile. Par contre, fournir uniquement des exemples de code pour l’exploitation tel ou tel fonctionnalité me semble beaucoup plus productif.
Pingback: Comparaison d’eZ Publish et Drupal | truffo.fr