Hells_Dark, le jeudi 26 août 2004, 22:19, dit :
Ok, en fait ça sépare le php (ou autres langages surement) du html, voire xhtml en quelque sorte ! C 'est cela ?
bonjour,
on pourrait dire ca
Citation
Et bien, je trouve cela tout bonnement géniale !
Quelqu'un a des remarque qui vont dans mon sens ou dans l'autre ?
Il y en a qui n'apprécient pas ? D'autres pourraient me dévoiler leur entousiasme ?
Bref, ça m'interresse, mais je veux plus d'avis avant de me lancer !
Le cout des moteurs de templates (charge serveur, contraintes, apprentissage, evolutivite, etc.) n'etant pas nul, l'usage de moteurs de template ne doit pas etre systematique.
Il y a des cas ou cela peut presenter un avantage certain (a condition de prendre le moteur de template qui correspond le mieux a un besoin precis) : travail collabaratif, etc. D'autres ou cela se revele particulierement penalisant.
De mes differents tests, je retiens qu'un moteur php doit habituellement etre couple a un ou plusieurs systemes de cache, sous peine de voir les performances fortement chuter (coef 2,3 ou plus). PHPBB par exemple permet 2 niveaux de cache (cache de code compile, cache HTML)
XLST est tres seduisant. Mais pour des traitements pointus - par exemple : la mise en page dynamique de forums IPB - l'exclusivite xml/xsl/xslt seule est une vraie calamite (necessite alors d'etre completee par php). Il y a aussi le probleme d'une gestion de page par "portions" (par exemple via une API), impossible en XSLT pur. J'attends beaucoup de l'evolution xml/xsl/php5.
Pour revenir aux 'moteurs de template' et autres applications destinees a separer le contenu de la mise en forme, prennons un cas que je connais particulierement bien : Invision Power Board. IPB n'utilise pas de moteur de template, mais separe le code php du reste, ce qui foncierement revient au meme. De nombreux utilisateurs ont trouve ce systeme trop limite. Maintenant avec la version 2.0, ils auront la possibilite de realiser des test (if/else) directement a l'interieur du layout.
Plus tard, ils voudront probablement pouvoir effectuer des boucles (for, while, foreach, etc), faire des appels a des fonctions, acceder a un maximum de variables, creer des routines, etc, etc.
A chaque fois, il faudra introduire de nouvelles fonctionnalites, y associer des traitements ad hoc, et - pour l'utilisateur - faire l'apprentissage d'un nouveau pseudo-langage de plus en plus lourd.
A partir d'un certain moment, a vouloir ameliorer un pseudo-langage associe a un moteur de template, on re-invente la roue. Avec des performances nettement moindres que php d'origine.
Mais encore une fois, a chaque probleme sa solution. il y a des cas (souvents simples) pour lesquels, parmi tous les moteurs disponibles, un moteur de template represente la solution optimale, cad, repond efficacement a un probleme donne.
Le tout consistant a definir ses besoins avec precision, et ensuite analyser avec attention les solutions proposees. Autrement, le meilleur moteur de template, le moteur le plus evolue, le plus leger et le plus complet, reste php lui-meme... a condition de coder proprement
Rasmus Lerdorf, le LinuxTag 2002, dit :
PHP est et restera un système de gabarits, même très évolué. Au début, c'était un outil pour me simplifier la vie avec les affichages HTML. Un jour, on m'a demandé d'ajouter l'instruction if, et je l'ai ajouté. Puis, on m'a demandé 'else', et naturellement, je l'ai ajouté. Et les boucles while et for ont suivi.. Certes, aujourd'hui, c'est bien plus qu'un simple langage de gabarit. Mais si vous regardez les applications de gabarits qui sont publiées, elles commencent aussi à intégrer des conditions et des boucles. Elles finiront par refaire ce que fait PHP, une couche au-dessus de PHP. C'est inutile!
plus d'informations :
The Deadly Sins of Templates in PHP
Ce message a été modifié par Dash - 26 août 2004 - 22:24.
Haut
