Bonjour,
 
je suis actuellement sur un stage et l'appli sur laquelle je bosse utilise des templates. je ne m'y connais pas vraiment mais j'aimerais savoir si les templates sont (encore) beaucoup utilisées sur des projets actuels.
 
merci  

Ca dépend ce que tu appelles template... Ca peut démarre avec une simple séparation genre accès aux données<->affichage, jusqu'à l'implémentation d'un langage complet dédié...

Je pense que l'utilisation d'un moteur de templates a tendance à se généraliser...en tout cas j'espère.

PHP and Templates

edit : meme lien qu'au dessus

Merci de coller exactement le même lien qu'au-dessus.
...et perso je suis pas d'accord avec la plupart de ses arguments, mais c'est une question de point de vue, je suppose...

sur mon appli, apparemment  c'est un moteur de Template. Smarty que ca s'appelle. Mais on m'a deja prévenu que ce moteur était un peu vieux

...bah c'est très bien smarty (oui, cet avis n'engage que moi).
 
Pourquoi tu demandes, en fait?
 

+1
 
C'est sur que si on se sert mal des templates, c'est nul comme outil... mais c'est pas pire que du php codé avec les pieds
 
edit:

Et re+1

bon c'est vendredi, un pti débat moteur de template, trop de la balle ! Et j'aimerais l'avis des partisans pro-template.
>C'est sur que si on se sert mal des templates, c'est nul comme outil... mais c'est pas pire que du php codé avec les pieds
ok donc c'est pareil quoi ... de l'affichage en PHP ça peut etre très propre si tu codes pas avec les pieds comme tu dis
 
Donc franchement, ok je veux bien croire que pour un intégrateur, c'est mieux de manipuler du langage de template que du PHP (on est en droit de douter quand on voit des structures conditionnelles ...).
 
Mais franchement, quand c'est vous qui faites l'intégration, je comprends pas l'intéret des moteurs de template. On est bien sur tous d'accord pour séparer la logique de présentation et la logique métier, mais à quoi ça rime d'avoir des {blabla} dans tous les sens plutot que des $display->blabla(); ?
 
Donc voilà, j'aimerais votre avis, si on considère que l'intégrateur sait faire du PHP, expliquez moi l'intéret de recourir à des templates et de devoir apprendre un nouveau langage à part entière ?

 
Faut pas que ça serve qu'à intégrer des variables dans du html non plus...
 
Ne serait-ce que des trucs comme la gestion du cache, ou des fonctions intégrées du style le html_options de smarty, ne pas réinventer la roue et utiliser du code éprouvé, quoi...

En plus des avantages qui citent skeye, pour moi c'est surtout: séparation métier/présentation.
 
Petit exemple, tu dois afficher le resultat d'une requete. La chartre graphique impose un html basé sur des table/tr/td
 
Si tu utilises des templates tu fais:
- un script php qui récupère les données correctement et les envoie à:
- un template smarty qui contient le code html
 
Si tu n'utilises pas de templates tu dois faire:
- un script php qui réupère les données correctement et ensuite fait des print table,tr,td
2 mois plus tard, toute la chartre graphique est changée en divs floatant toussa toussa.
Avec les templates, tu n'as pas besoin de toucher à tes traitements en php, sans template si ( au risque de tout casser ( risque faible sur cet exemple je te l'accorde mais pas sur de plus grosses problématiques))...
 

 
Tu peux faire ce genre de choses en php sans moteur de templates...c'est là que veut en venir l'article cité plus haut...

>En plus des avantages qui citent skeye, pour moi c'est surtout: séparation métier/présentation.  
 
comme dit plus haut, pas besoin d'un moteur de template pour faire ça.
 
>Ne serait-ce que des trucs comme la gestion du cache, ou des fonctions intégrées du style le html_options de smarty
 
ok donc là ça me semble déjà plus crédible
donc au final, tu te sers d'un moteur de template pas vraiment pour son langage de template, mais pour ses fonctionnalités "à côté" ?
 

Bah c'est un outil comme un autre, quoi...personnellement je trouve que faire autrement serait moins pratique et une perte de temps, et le "langage" est vraiment pas compliqué à assimiler...

Comment alors
 
A moins de se faire son moteur template sauce perso, je vois pas d'autres solutions pour séparer html & php, mais je serais ravi d'en découvrir!
 
edit:

Bin la gestion du cache pour le coup tu peux vraiment la faire autrement, par exemple http://fr2.php.net/manual/en/ref.apc.php

 
simple.
Exactement comme avec un truc genre smarty, sauf qu'au lieu d'appeler $smarty->display() tu fais un include de ton template en php...

 
 
HTML != présentation.
 
 
Comme dit dans l'article... le code ne peut pas être totalement séparé du contenu.

   
Pas d'accord ton include est en php et non en html! Qu'est ce que ça change? Bin avec un warning_all si tu as un

tu prends un beau warning dans ta page.
Et même avec ta technique je serais ravi que tu me montres l'exemple que la boucle pour l'affichage du tableau décrit plus haut!
Tu ferais comment un include pour le table, une boucle et un include par tr?

D'accord "présentation" était mal choisi, j'aurais du utiliser "flux retourné par ton script"
 
C'est pas parce que l'article le dit que c'est vrai ( ou qu'au moins je suis d'accord ).
Mais je serais ravi que tu nous donnes un exemple ou le code ne peut être séparé du contenu.

(quel tableau décrit plus haut? )
 
euh mais ton fichier "template" serait un bête script php comme les autres, sauf qu'il est censé être appelé avec une liste de variables déjà initialisées, c'est tout...ça te permet de ne modifier que ces scripts-là en cas de modif de la couche présentation, et pour un coût similaire à celui que ça aurait avec un moteur de templates...

 
D'après toi c'est quoi le {foreach} dans smarty?
 
Il ne parle pas du code "métier", du moins je l'espère...

le but c'est pas de séparer html et PHP, mais de sépare logiquer métier et logique de présentation.
 
Ca rime à rien de vouloir utiliser un moteur de template pour ne pas avoir une seule ligne de PHP dans ton html : tu te retrouves avec les même structures conditionnelles, mais ... en langage template.
 
Moi personnellement :  
mon controller recup la demande utilisateur et lance l'action de la logique métier, puis instancie la View qu'il faut.
Dans ma view, il n'y a aucun traitement, aucune analyse, bref, pas de logique métier, que de l'affichage.
Un exemple tout con, si un utilisateur veut se connecter :
 
1) le controller instancie la classe gérant la connection (verif dans la base ds logins mdp, et instanciation d'un objet User si la connection réussie
2) le controller met l'objet User en session et redirige sur la page d'où tu as demandé la connection.
3) pour chaque page, le controller vérifie s'il y a un objet User en session.
- s'il y en a pas, il lance l'affichage d'un message de non-connection (par exemple $display->notconnect() ).
- s'il y en a, il lance l'affichage des infos de l'utilisateur, en transmettant l'objet User à la view (par exemple $display->connect($objuser) )
4) La view a donc deux méthodes dans notre cas :  

 
et dans le controller, simplement :  

 
Voilà, pas un brin de logique métier dans la présentation, mais bel et bien du PHP.
Je dis pas que ma méthode est la meilleure, mais c'était pour montrer que séparer html et PHP != séparer présentation et logique métier

Celui la:

Quelque chose utilisé pour afficher un tableau, rapport avec le code métier? aucun ...
 

Alors là d'accord
 

Au contraire, je prends une appli que je developpe en ce moment.  
1 partie ajax, 1 partie "normale" html.
D'un coté nos objets métiers, de l'autre un moteur de rendu qui renvoit selon le cas un flux xml parsé en js ou un flux html interperté par le navigateur. Je peux pas avoir d'html(edit): de notions de rendu dans mes objets métiers...
 

Je suis entièrement d'accord avec ta dernière phrase...
Mais dans ton exemple tu as une classe qui s'occupe de l'affichage, que ça soit la tienne ou une smarty je vois pas trop la différence ... Sauf qu'avec la tienne si je veux changer le flux sortant c'est le php qu'il faut que je modifie
edit: Comme le disait Skeye pourquoi ré-inventer la roue, des moteurs de templates existent et sont éprouvés, fournissent plus de fonctionnalités que les choses que l'on peut faire soi-même... Pourquoi s'en priver ou ré-inventer la roue!

Justement, pour réinventer la roue en inventant un langage de template, alors que PHP fait ça très bien ?

Si les moteurs de templates n'apportaient rien, effectivement.

Je préfère une lib de fonction PHP pour générer facilement de l'HTML qu'un truc qui repose sur (encore) une autre syntaxe. Déjà que je doit jongler avec l'HTML, le CSS, le Javascript, le PHP, l'XML, le machin, le bidule, si je dois encore rajouter une syntaxe de template, bonjour
 
En plus ça impose que tout le monde connaisse la syntaxe du moteur de template. Ca fait un savoir de plus à maîtriser dans la boîte Alors c'est sûr que la syntaxe est un peu plus légère, qu'on ne se retrouve pas avec une template capable de vider la base de données, mais bon...
 
Sans parler que ça fait un truc tierce-partie en plus, avec ses bugs, ses problèmes, les risques que le projet soit abandonné (bon pour Smarty c'est assez peu probable)...

Les 2 points de vue se défendent...perso j'utilise smarty, j'en suis content, et après vous faites ce que vous voulez!

C'est ce que j'allait dire

Quel bel argument...foireux!
PHP ne fait pas ça très bien, c'est tu peux faire des scripts en php faisant ça très bien mais il n'existe aucune fonction php "de base" offrant les fonctionnalités de templates comme smarty!
A ce moment la pourquoi utiliser n'importe quelles fonctions de cette liste alors que tu pourrais tout refaire toi-même?

Les fonctions, je les faits moi-même, et y'a pas besoin de parser un nouveau langage...
 

Ne confond pas tout...
 
 
Sinon, un post à lire sur sitepoint.com

C'est marrant je suis entierement d'accord avec cet article et surtout avec cette partie:

 
Donc je suis d'accord, on peut faire sans template en faisant tout soi-même... Mais dans 99% des fois le résultat sera plus buggé, lent, moins fonctionnelle qu'en utilisant des trucs "tout fait"...
 
Exactement l'argument qu'il cite sur l'utilisation des couches d'abstraction de base de données vis à vis de classes "personnelles" de connexion.
 
edit: a si la dessus je suis pas tout a faire d'accord:

Dans un mode idéal, effectivement ... Maintenant du code html fait par un "WebDesigner" sous Dreamweaver à base de tableau, j'en vois encore passer beaucoup! Et le jour où faut tout refaire...

C'est n'importe quoi ce que tu dis. J'ai l'impression que tu confond "template" et "langage de template".  
 
Ensuite moi avec mes fonctions customisées PHP, j'ai aucun problèmes. Ne me dit pas que que développer une petite fonction qui t'affiche une liste d'<option> est compliquée à faire... C'est fait en 15 minutes, et ça ne peut être qu'aussi rapide qu'un autre système de template (à part s'il est sous forme d'extension). Je vois la fonctio html_options de Smarty là, faut quand-même pas être un dieu pour refaire pareil

+1000 avec FlorentG
L'argument comme quoi faire une pauv fonction affichant une liste, c'est moins optimisé qu'avec smarty, c'est bidon ^^
 
Moi ce qui me rend réfractaires aux templates :
- il faut une phase de parsing, c'est du n'importe quoi
- PHP est déjà un langage de template
- je n'ai aucune envie d'apprendre la syntaxe d'un langage, qui en plus n'est pas censé être un langage de programation, mais qui possède des fonctions, des structures conditionnelles ... un truc de fou quoi pour un langage de non-programation
- je voie pas en quoi un intégrateur aurait plus de mal à apprendre un if en PHP que un if avec smarty
- je pense personnellement (mais là on va me taper) qu'un intégrateur à rien à foutre avec du html entre les mains, un css lui est largement suffisant
 
C'est pour ça que je trouve personnellement que un moteur de template ne sert à rien pour séparer présentation et logique métier. Alors après, si on me dit que c'est pour bénéficier d'outils éprouvés et optimisés (genre système de cache), là je comprends déjà mieux

si on se mets a chipotter sur les mots c'est plutot "moteur de template" que "langage de template" que j'ai omis ...
 

Et si quelqu'un doit reprendre ton code, est ce que cela sera aussi facile pour lui?
 

15 mins... pour arriver à quelque chose qui fait pareil et aussi bien. Donc 15 minutes de perdu si je pousse la logique jusqu'au bout.
 
Encore une fois je reprendrais son argument principal "People who use PHP aren't software developers" donc ton cas personnel n'est pas vraiment un argument(vu que je ne pense pas que tu sois dans ce cas). Combien de questions sur ce forum sont posées par des gens ignorant tout d'une architecture client-serveur et pourtant "payés" pour faire un dev en php!!!
 
sur ce we

Y'a déjà l'avantage d'avoir une syntaxe 100% PHP, donc pas de trucs bizarres
 

J'vois que t'es à 15 minutes près dans la vie Ensuite les fonctions de Smarty là me plaisent pas, donc de toute manière j'aurais utilisé autre chose
 

Je vois pas trop alors comment ils s'en sortiraient mieux avec un moteur de template en plus à apprendre à côté

oula je voulais pas déclencher une guerre moi    
Donc apparemment c'est partagé. Mais dans les faits le pourcentage de projets utilisant des moteurs de template?  
 
Surtout ne me dites pas ca dépend    (j'ai horreur de cette expression)
(Il y a forcément une moyenne, en prenant en compte tous les critères que vous pouvez trouver)

@anapajari : j'ai l'impression qu'en fait tu conseilles l'usage des moteurs de template pour limiter les erreurs de prog. Et ça rejoint l'argument donné plus haut que quand on fait ça en PHP, c'est crade.
Donc, en gros, moteur de template, c'est fait pour les mecs qui savent pas développer ?    
Tout ce qui est faisable avec smarty est faisable tout aussi proprement en PHP, sans rajouter une phase de parsing et un nouveau langage à apprendre.
 
edit pour au dessus : beaucoup
edit pour en dessous : vi voila, donc smarty permet de séparer la logique de présentation au moins lol  

98% des projets PHP sont en général de grosses merdes fumantes où SQL, PHP et output sont mixés (avec en sus l'output sous forme d'HTML + tableau + scripts tout en même temps)

et les moteurs de template dans tt ca? combien de % des projets ?