[Templates] Quel système utilisez-vous ? Pourquoi ? - Page 10

naholyr · 12/08/2005, 17h37

Citation:

Envoyé par melmel

Bonjour,

Je ne pense pas qu'il a été posté alors voilà :
http://www.massassi.com/php/articles/template_engines/

J'ai découvert cet article en cherchant comment un template fonctionnait et j'avoue qu'il m'a appris bcp de choses.
Le moteur de template n'utilise que php. Je veux dire par là qu'il n'y a pas de langage interne propre au moteur. Tout est en php.
Dans l'article il dit que ca a déjà été fait (cf page 2 de l'article) mais je n'arrive pas à trouver d'autres exemples que le sien.
Connaîtrez-vous un moteur similaire ?

Je crains que tu n'aies pas bien compris le principe

Ce n'est pas un moteur de template. C'est PHP le moteur de template dans sa librairie. Lui ce n'est qu'un "distributeur de variables" si je puis dire. Ce qu'il démontre avec brio c'est justement l'ineptie fondamentale de la plupart des moteurs de templates.

melmel · 12/08/2005, 20h17

Citation:

Envoyé par naholyr

Ce n'est pas un moteur de template. C'est PHP le moteur de template dans sa librairie. Lui ce n'est qu'un "distributeur de variables" si je puis dire. Ce qu'il démontre avec brio c'est justement l'ineptie fondamentale de la plupart des moteurs de templates.

Mais "distribuer des variables", c'est ce que font tous les moteurs de template, non ? Je ne vois pas bien la différence entre son exemple et les autres moteurs de templates.
Le principe d'un moteur de template, c'est bien de séparer tout ce qui est logique (php, requetes sql) du design (html, css..), non ? ou bien il y a qqch en plus qui caractérise un moteur de template ?

melmel

doof · 12/08/2005, 20h19

Ca reste néamoins un "cadriciel" de template, le mot "moteur" en ce sens reste subtile et à l'appréciation de chacuns.

PHP est un moteur de templates en lui même, surement le meilleur, mais il n'a jammais eu de cadriciel clair, laissant plusieurs tentatives naitre, en oubliant ce qu'était une des forces principales de php à la base.

Force est de constater qu'aucun n'arrive à la cheville de php, je défendais flexy dernièrement, mais je l'ai finalement abandonné, puisque, comme tous les autres, je me suis retrouvé à un moment limité. Les avantages que je lui trouvais à l'époque, avec l'arrivée de php5 n'en sont plus : la manipulation DOM se fait très bien avec l'extension DOM comprise de base dans php5, le filtrage automatique des variables, se gère facilement soit en __get(), soit en __set()... Et l'on dispose en plus de toute la puissance du langage php.

Oui, j'ai changé d'école (j'ai eu une révélation : tout système de template alternatif est une perte de productivité, et même de bon sens ) et il fallait quand même que je l'avoue.

doof · 12/08/2005, 20h53

Ca fait 5 ans que je perd mon temps avec des "moteurs de templates", dans le sens où avec chacuns, j'ai a un moment ou un autre dû lutter pour représenter quelquechose un tant soit peu légèrement complexe. Pour l'anectdote, j'avais toujours eu depuis le début un solution avec PHP.

Mais là où je me fourvoyais : surtout "ne pas mélanger php avec du html", l'erreur de tous ces "systèmes" répercuté sur ma façon de voir les choses... Je maudit maintenant celui qui est à l'origine de ce mauvais tournant.

Séparer présentation et logique métier ne signifie en rien séparer php/html, et utiliser un langage limité-hybride/html n'est certainement pas une solution interessante, il faudrait qu'elle amène au moins une possibilité nouvelle (ce que le seul sachant le faire était flexy : manipulation dom).

Pour ma façon de séparer les choses, il n'y a rien de plus simple : je remplis un objet me servant de conteneur de variables à afficher (nommé $datas dans la plupart des cas), l'objet $view (template php/html le plus souvent) se charge de l'afficher à sa guise.

naholyr · 12/08/2005, 21h21

Comme l'a si bien rappelé doof, ne pas mélanger présentation et logique métier ne signifie pas séparer html et php.

Ce triptique-ci n'utilise pas de "moteur de template":

presentation.htm

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<html>
...
<h1>Bienvenue <?=$pseudo?></h1>

metier.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?php
 
$db = new DB;
$res = $db->query(...);
...
$pseudo = $row->pseudo;
 
?>

index.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<?php
 
// calcul
include "metier.php";
 
// présentation
include "presentation.htm";

Est-il vraiment moins lisible que ce triptique-là ?

presentation.htm

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<html>
...
<h1>Bienvenue {pseudo}</h1>

metier.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?php
 
$db = new DB;
$res = $db->query(...);
...
$pseudo = $row->pseudo;
 
?>

index.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
<?php
 
// calcul
include "metier.php";
 
// présentation
include "moteur-de-template.php";
$tpl = new Template("presentation.htm");
$tpl->set("pseudo", $pseudo);
$tpl->display();

Au final avec un moteur de templates "classique" on :
- perd en performance (surcouche)
- ne gagne pas en lisibilité

Les arguments en faveurs de moteurs existant sont :

Les designers peuvent faire le template d'un côté, le programmeur le remplit
Argument à 2 balles

Il est aussi sinon plus facile d'insérer <?=$variable?> dans Dreamweaver que {variable}, d'autant plus qu'avec la coloration syntaxique (tout éditeur confondu) on mettra plus facilement en évident les variables PHP que "template".

On peut passer d'un langage à l'autre avec la même présentation
La conversion est de l'ordre du simple chercher-remplacer "<?=" par "{" et "?>" par "}", tout au plus 5 minutes pour un lot de fichiers, pour convertir d'un format à un autre...

zax-tfh · 16/08/2005, 11h24

Absolument, par contre pour ton probleme de cache, c'est peut etre normal non ? si ton fichier de template faisait 2Ko, as tu pensé aussi que le cache une fois "templatisé" (donc que le moteur de tpl a fait son job en placant les données à l'interieur) beh les données placées auraient pu donner ces 4Ko supplémentaires ?

Sinon pour ce qui est de bannir les tpl, je suis pour ^^ la syntaxe donnée juste au dessus est aussi simple, voire plus simple que celle d'un moteur de template. Faut juste que je reflechisse sur ses faiblesses à long terme sur des cas particuliers mais je ne pense pas en rencontrer

hugo123 · 16/08/2005, 11h27

Tu as justement pointé sur la différence zax-tfh.
Smarty va créer des pages statiques (et c'est bien pourquoi elles sont plus lourdes que ton code php) qui ne seront pas recompilées a chaque fois.
Donc la syntaxe évoqué plus haut n'est équivalente que pour la mise en page et la pseudo séparation du code et du html.

zax-tfh · 16/08/2005, 11h33

Oui donc après c'est à chacun de decider ce qu'il veut, soit il met en cache son contenu si le serveur n'est pas ultra puissant ou pour éviter moulet calcul si ce n'est pas nécessaire, soit il ne met pas en cache et donc gère le couple PHP/MySQL.

Personnellement je suis sur un developpement de portail web (type CMS) et je vais mettre en place le cache de cette maniere : tout ce qui n'est pas strictement dynamique, gestion en cache comme pour les articles par exemple. Et lors de leur edition, suppression je régénere le cache. Comme ceci, il n'y a que du html qui est envoyé ce qui je pense doit alléger la requete. Car au final si on y reflechi : les données envoyées sont les memes :

Technique php/mysql : requete->traitement du serveur->parsage des donnéées en html->envoi au client
Technique avec cache : requete->traitement du serveur->parsage des donnéées en html->envoi au client

Sauf que entre les deux techniques c'est le traitement du serveur qui va différer. Dans le premier : le tratement sera plus lourd sachant qu'il va devoir rapatrier toutes les données et les mettre en page. Dans la deuxieme méthode, il n'y aura qu'une éventuelle lecture de base de données pour savoir ou se trouve le fichier de cache et basta. Apres le reste est déja fait niveau mise en page et tout ça.

Donc pour moi le mieux est de mettre en cache...ca n'engage que moi.
++

zax-tfh · 16/08/2005, 12h09

C'est là ou je me dis que la mise en cache telle qu'elle est gérée ne me plait pas... On lui donne une durée, mais qu'est-ce qui fait dire qu'au bout de tant de temps il faut régénérer le cache ? Pour moi on doit le refaire à partir du moment ou on change son contenu (cf mon exemple avec les articles)...M'enfin c'est mon point de vue, je pense que cela doit bien servir à moult applications. Mais en fait ça illustre ma vision globale de tout ça : pourquoi faire compliqué quand on peut faire simple ? Ces moteurs gèrent tellement de trucs qu'on ne sait meme pas si on l'exploite vraiment ou bien si c'est juste pour dire qu'on utilise un moteur de tpl et qu'en fait on n'en exploite que 2%. Au départ quand j'utilisais phplib, c'etait uniquement pour parser des variables (donc vraiment uniquement ce qui a été montré en code plus haut).... et je pense que tout le reste qui était géré par phplib ca ne me servait à rien mais devait bouffer de la ressource quand meme....donc inutile. Rien ne vaut un bon truc maison que l'on maitrise completement.

hugo123 · 16/08/2005, 13h40

Tout a fait, je te rejoins lorsque tu dis "Rien ne vaut un bon truc maison que l'on maitrise completement." Mais ce raisonnement vaut aussi bien pour le php. Tu maitrises aujourd'hui le php, donc tu t'en sors bien, mais avant ca tu as du lire la doc et tatonner. Les moteurs de templates, c'est pareil, il faut lire la doc et tester. Smarty permet d'utiliser une gestion de cache spécifique, il peut définir des parties dynamiques dans une page statique et bien d'autres choses. En plus dans la doc il y a tout un chapitre qui est dédié a ca.
Ensuite chacun fait son choix comme l'a dit Poof, mais pour pouvoir faire un choix il faut le faire en connaissance de cause.

zax-tfh · 16/08/2005, 13h44

D'accord à 100%. Mais en fait ce qui est bien là c'est qu'on donne nos points de vue sans se bouffer le nez comme dans la plupart des forums, et ça c'est trop top car c'est une discution constructive (la premiere que j'apprecie autant je crois d'ailleurs

) et les personnes qui liront ce topic auront des avis qu'ils choisiront selon leurs besoins.

Pour smarty, je ne le remet pas en question en fait. Juste que j'ai bien envie de faire ma mouture a moi ^^
Cela dit je pense fortement qu'il doit etre interressant, à voir comment tout le monde en parle.

hugo123 · 16/08/2005, 13h56

Je l'utilise depuis peu, avant j'avais mon propre système. Mais il n'était pas terrible et j'ai vraiment gagné en perf (et c'est plus facile a modifier aussi). Certains le disent lent par rapport a d'autres moteurs, mais je n'ai pas pu comparer. Par contre avec la gestion du cache, sur de grosses quantité de données, j'ai bcp gagné par rapport a des pages php sans moteurs. D'autres le jugent trop complexes, un designer web peut avoir du mal a éditer les templates.
Je pense par contre que son intérêt, c'est d'éviter de refaire ce qui a déjà été fait. Faire son moteur a soi c'est possible, mais ca prend du temps, il faudra faire face a des pbs qui ont déjà été réglés par d'autre et le temps on ne l'a pas toujours. C'est aussi avec ce raisonnement que j'utilise les librairies PEAR a fond plutot que de faire du spécifique ^^
J'ai toujours une interface d'admin qui n'utilise pas smarty par contre. Ca me permet de comparer sur des pages qui affichent a peu près les mêmes données (gestion des news et affichage des news par exemple).

GrandFather · 16/08/2005, 17h01

Bonjour,

j'ai lu avec intérêt tout le thread, et je voudrais apporter un bref commentaire.

Il y a au moins un contexte dans lequel l'utilisation d'un langage de templates comme celui de Smarty offrira davantage de lisibilité et de souplesse que PHP seul, c'est celui de la génération de flux XML. J'illustrerai mon propos avec un exemple de template Smarty générant du XML dans une de mes applis :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?xml version="1.0" encoding="ISO-8859-1" ?>
<commentaires exercice="{$exercice}" appreciateur="{$appreciateur->numero}">
	{if $erreur neq ""}
  	<erreur>{$erreur}</erreur>
	{else}
		{section  name=idx loop=$commentaires}
  		<commentaire>	
  		 	{include file="agent.xml.tpl"}		
      	<commentaire_agent>{$commentaires[idx]->commentaire_agent|escape_xml_entities}</commentaire_agent>
      	<commentaire_appreciateur>{$commentaires[idx]->commentaire_appreciateur|escape_xml_entities}</commentaire_appreciateur>
      	<commentaire_responsable>{$commentaires[idx]->commentaire_responsable|escape_xml_entities}</commentaire_responsable>
      	<responsable nom="{$responsable_unite->nom}" prenom="{$responsable_unite->prenom}"/>
      	<appreciateur nom="{$appreciateurs_directs[idx]->nom}" prenom="{$appreciateurs_directs[idx]->prenom}"/>
  		</commentaire>
		{/section}		
	{/if}
</commentaires>

XML oblige, l'utilisation de la syntaxe abrégée pour les balises PHP est interdite. Par conséquent, avec PHP seul, il faudrait utiliser des <?php echo ... ?> ce qui alourdirait nettement l'écriture du template, surtout pour les valeurs d'attributs.

D'autre part, une des contraintes du XML bien formé est que les caractères <, >, ' et " doivent être remplacées par leurs entités HTML pour éviter une erreur de parsing. Il m'a suffit d'écrire le modificateur de variables escape_xml_entities pour réaliser cela, et de l'ajouter à Smarty sous forme de Plugin. Pour montrer que cela n'a rien de bien sorcier d'étendre Smarty (il suffit de respecter les conventions de nommage), voici le code complet du Plugin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
<?php
 
function smarty_modifier_escape_xml_entities($string) {
        $patterns = array("'(&)([^(lt;|gt;|quot;|apos;|amp;)])'", "'<'", "'>'", "'\''", "'\"'");
        $replace = array('\\1amp;\\2', '&lt;', '&gt;', '&apos;', '"');
        return preg_replace($patterns, $replace, $string);
}
 
?>

Vous l'aurez deviné, je suis plutôt pour l'utilisation d'un moteur de templates (et de Smarty en particulier).

doof · 16/08/2005, 18h13

Il est vrai que l'utilisation de <?php echo... ?> était une étape psychologique qui me rebutait, mais j'ai redécouvert un truc excellent depuis que j'utilise ce système : la coloration syntaxique ! Quel bonheur de voir les parties dynamiques de mon template directement colorées par mon éditeur ! Donc niveau lisibilité, même si c'est légèrement plus verbeux, je trouve au contraire qu'on y gagne.

Je n'ai pas bien compris l'avantage de smarty pour l'histoire des entités HTML, en quoi étendre smarty par une fonction apportera "plus de souplesse" que de définir cette même fonction en php et tout simplement l'utiliser ? Même si tu nous montre que ça n'est pas si compliqué avec smarty, je ne vois pas l'avantage qu'apporte un moteur de template dans un ce spécifique.

:

GrandFather · 16/08/2005, 20h00

Citation:

Envoyé par doof

Il est vrai que l'utilisation de <?php echo... ?> était une étape psychologique qui me rebutait, mais j'ai redécouvert un truc excellent depuis que j'utilise ce système : la coloration syntaxique ! Quel bonheur de voir les parties dynamiques de mon template directement colorées par mon éditeur ! Donc niveau lisibilité, même si c'est légèrement plus verbeux, je trouve au contraire qu'on y gagne.

Cela est évidemment subjectif, mais je préfère avoir à maintenir ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<?xml version="1.0" encoding="ISO-8859-1" ?> 
<commentaires exercice="{$exercice}" appreciateur="{$appreciateur->numero}"> 
   {if $erreur neq ""} 
     <erreur>{$erreur}</erreur> 
   {else}

plutôt que celui-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<?xml version="1.0" encoding="ISO-8859-1" ?> 
<commentaires exercice="<?php echo $exercice ?>" appreciateur="<?php echo $appreciateur->numero ?>"> 
   <?php if ($erreur != "")  { ?> 
     <erreur><?php echo $erreur ?></erreur> 
   <?php } else { ?>

Citation:

Envoyé par doof

Je n'ai pas bien compris l'avantage de smarty pour l'histoire des entités HTML, en quoi étendre smarty par une fonction apportera "plus de souplesse" que de définir cette même fonction en php et tout simplement l'utiliser ? Même si tu nous montre que ça n'est pas si compliqué avec smarty, je ne vois pas l'avantage qu'apporte un moteur de template dans un ce spécifique.

:

Plusieurs avantages :

escape_html_entities étant une fonction d'intérêt général, on a tout intérêt à la placer dans une librairie. Dans un système de template en PHP pur, il est nécessaire de l'inclure avec require_once partout où elle est utilisée ; avec le mécanisme de plugin de Smarty, l'inclusion est transparente pour le développeur (et sans risque de collision de noms)
Avec Smarty, il est possible de chaîner des modificateurs de variable en les séparant avec le pipe :
Code :

Sélectionner tout - Visualiser dans une fenêtre à part
```
{$exercice|escape_xml_entities|capitalize}
```
La même chose en PHP pur, et sans utiliser de variables intermédiaires, nécessite d'imbriquer les appels de fonctions ; cela n'améliore pas la lisibilité, et finit par faire ressembler PHP au LISP.

Beaucoup d'autres fonctionnalités qui allègent le travail des développeurs, comme la gestion ultra-simple des cycles de couleurs dans une table par exemple, m'ont attiré vers Smarty. C'est lorsqu'on met en oeuvre toutes ces fonctionnalités dans un projet de taille moyenne/grande qu'on peut véritablement juger de l'intérêt d'un moteur de template, surtout couplé à un framework MVC.

naholyr · 16/08/2005, 20h56

GrandFather pointe le doigt sur les deux seuls avantages indéniables des surcouches templates :
- L'abbréviation pour les traitements de caractères ayant très à la présentation (la mise en capitale, l'htmlentitiesation, etc... font partie de la présentation et devraient donc idéalement être dans le template).
- L'utilisation dans le cas d'XML où la syntaxe allégée est impossible. Enfin un bémol là-dessus : on peut tout-à-fait utiliser la syntaxe allégée il suffit de changer le prologue XML de <?xml ... ?> en <?='<?xml ... ?'.'>'?>. Si cette première ligne sera peu lisible le reste le sera un peu plus. Mais dans les deux cas il y a une contrainte.

Ces deux points ne me suffisent pas, et j'avoue être ravi de voir le retour en arrière global opéré ces derniers temps.

doof · 17/08/2005, 08h08

GrandFather, je ne remet pas du tout en cause l'utilité d'un système de templates, j'en suis moi même un inconditionel, et parfaitement d'accord sur le fait que c'est indispensable pour travailler proprement dans un style modèle vue controleur (j'aime pas le mot framework, je m'y sent à l'étroit)

J'insiste simplement sur le fait qu'utiliser php comme langage de template me semble plus judicieux qu'un autre pseudo langage, et aussi sur fait que le parseur de PHP se comporte déjà à la manière des templates.

Tous les avantages que tu donnes plus haut se résolvent sans problème en utilisant PHP, il faut juste se faire une base objet pour encadrer tout ça bien évidement, je t'invite à regarder sérieusement le fonctionnement de Savant, qui de façon simple, n'a rien a envier à Smarty, tu y retrouvera tous les avantages que tu donnais plus haut (cadriciel, plugins, filtres...), sauf qu'ici le langage de template est php. La lecture de son code est d'ailleurs déconcertante de simplicité et instructive.

Concernant l'abrévation du code, comme le souligne naholyr c'est effectivement le seul avantage que l'on pourait trouver avec un système de template à code auto généré, mais je le trouve bien maigre. Concernant les filtres pipés, on pourrait très bien arriver à quelquechose sensiblement similaire en php :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<?php $this->_o($exercice,'escape_xml_entities','capitalize', ...) ?>

Et l'on évite donc le l'enfert LISP

[instant poilu]Tu fais beaucoup de XML, tu devrais aimer ce qui est lourd et verbeux non ? je rigole hein

[/instant poilu]

Et sinon, juste un p'tit truc par rapport à l'exemple de code que tu donnes : PHP admet pour les boucles et conditions une syntaxe alternative : if: .... endif; foreach:....endforeach; ce qui est plus sympas dans un template que les accolades difficilement lisibles (on dirait d'ailleurs que cette syntaxe a été spécialement prévue pour les templates).

Un nouvel avantage venu avec la sortie de php5 et de sa spl est la surcharge du foreach permetant de faire des bouclages simplement et de manière adaptée à la structure à représenter, je trouve ça idéal pour les templates.

GrandFather · 17/08/2005, 09h29

Citation:

Envoyé par doof

J'insiste simplement sur le fait qu'utiliser php comme langage de template me semble plus judicieux qu'un autre pseudo langage, et aussi sur fait que le parseur de PHP se comporte déjà à la manière des templates.

Je devrais préciser un peu le contexte qui m'est propre, pour justifier du choix de Smarty dans mon cas. Je dirige une petite équipe de développeurs qui ont un niveau de maîtrise de PHP qui va de néophyte à initié (nous n'avons pas de designer Web). L'avantage d'une syntaxe simplifiée comme celle de Smarty est de permettre de répartir efficacement le travail, les templates sont écrits par les moins balaises en PHP, la logique métier par les développeurs plus aguerris. Sur le plan de la productivité, cela me semble plus intéressant, mais cela reste cependant à vérifier sur le long terme. Sur un plan plus didactique, je ne suis pas mécontent que le langage de présentation soit différent de celui de la logique métier ; conceptuellement, cela oblige les développeurs à bien séparer les deux couches, et les éloignent de la tentation de les mélanger...

Citation:

Envoyé par doof

Tous les avantages que tu donnes plus haut se résolvent sans problème en utilisant PHP, il faut juste se faire une base objet pour encadrer tout ça bien évidement, je t'invite à regarder sérieusement le fonctionnement de Savant, qui de façon simple, n'a rien a envier à Smarty, tu y retrouvera tous les avantages que tu donnais plus haut (cadriciel, plugins, filtres...), sauf qu'ici le langage de template est php. La lecture de son code est d'ailleurs déconcertante de simplicité et instructive.

J'ai bien conscience que Smarty n'est pas la panacée. Savant a l'air intéressant, mais pour les raisons que j'ai évoquées plus haut, et donc tant que je n'ai pas une équipe de développeurs au niveau homogène, je ne préfère pas l'utiliser.

Citation:

Envoyé par doof

Concernant l'abrévation du code, comme le souligne naholyr c'est effectivement le seul avantage que l'on pourait trouver avec un système de template à code auto généré, mais je le trouve bien maigre. Concernant les filtres pipés, on pourrait très bien arriver à quelquechose sensiblement similaire en php :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<?php $this->_o($exercice,'escape_xml_entities','capitalize', ...) ?>

Et l'on évite donc le l'enfert LISP

[instant poilu]Tu fais beaucoup de XML, tu devrais aimer ce qui est lourd et verbeux non ? je rigole hein

[/instant poilu]

Je persiste à trouver cette syntaxe moins lisible que celle de Smarty, et plus pénalisante en terme de maintenance.
[réponse velue]Justement, XML est assez verbeux comme cela.

[/réponse velue]

sekaijin · 07/09/2005, 16h46

Citation:

Envoyé par doof

GrandFather, je ne remet pas du tout en cause l'utilité d'un système de templates, j'en suis moi même un inconditionel, et parfaitement d'accord sur le fait que c'est indispensable pour travailler proprement dans un style modèle vue controleur (j'aime pas le mot framework, je m'y sent à l'étroit)

J'insiste simplement sur le fait qu'utiliser php comme langage de template me semble plus judicieux qu'un autre pseudo langage, et aussi sur fait que le parseur de PHP se comporte déjà à la manière des templates.
...

Je regrète personelement qu'on ne puisse pas en php définir de fonction dont les argument ne sont pas interprétés. et les argument nommés plus précisément étendre la structure du langage.

en tcl par exemple il est possible de définir de telles fonctions.
il devient simple de faire les fonction html, html_p , html_div html_body
qui s'utilise comme suit.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
html {
  html_head {
    html_title {coucou $test}
  }
  html_body bgcolor=$color {
...
  }
}

au final lorsque je faisais du web en tcl jamais je n'avais à faire de print ou de écho de tag et je n'étais pas géné par les argument qui contiennent des " ou de '

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo "<div style=\"bacground-image('monimage.gif')\">truc</div>";

devient

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
html_div style="bacground-image('monimage.gif')" {
  truc
}

bref on ne fait plus de html mais du code et pas de pb de template.

au mieux en php je vais pouvoir définir une fonction qui prends un contenu et une chaine d'attributs. mais ça ne résoud rien.

au final les template sont une solution de pis aller.

quant à prendre php comme moteur de template
- c'est efficasse : pas de double interprétation du template pour générer la sortie. avec un template il faut interpréter le php du moteur plus le template.
- moins gourmand en memoire. avec un template on stoque le template, les segments d'analyse syntaxique, les segments de production et le resultat. avec php une bonne part de tout ça disparait.

mais utiliser php et déliquat
- il faut veiller à rester à sa place. un template doit rester un template et ne rien faire d'autre.
- c'est difficilement accéssible pour un non programmeur. un designer accepte facilement d'écrire {NOM} dans la zone qui doit contenir un nom car ça parait logique. <?php echo $nom ?> est déjà beaucoup moins apprécié.

A+jyt

sekaijin · 08/09/2005, 14h01

mon propos n'est pas de dire que c'est mieux où moins bien.
je note simplement que pour faire une appli web en php il faut connaitre minimum 2 langage. php et html
et qu'à un moment ou un autre on mixe les deux.

le fait de passer par un système de template ne fait qu'ajouter un language. php html et le language de template. et qu'au lieu de mixer php et html on mixe le langage de template et html.

la solution que proposais tcl avait le mérite de ne plus proposer qu'un seul langage.

quant à savoir comment on sépare le code de l'affichage aucune de ses trois approche ne le garantit.

php + html n'implique pas necéssairement qu'on mélange le code métier avec le code d'affichage

php + tpl + html ne garantit pas qu'on ne mettra pas de html dans le code metier.

de même l'approche proposé par tcl ne garantit pas la séparation des couches.

pour ma part je code php en objet et je sépare les couche comme suit

Classes d'accès aux données
Controleur d'accès au données (aux classes d'accès aux données)
Classes métiers
Controleur appllicatifs (Logique applicative)
Classes de présentation (qui utilise ou pas un système de template)

la couche présentation et assuré par les classes de présentation. aucune autre clase ne contient d'élément relatif à l'affichage.
totalement écrite en php la séparation des couche est tout de même assurée.
si elle utilise un moteur de template même topo.

c'est bien l'architecture de programmation qui me garantie cette séparation pas l'usage d'un moteur de template.

alors appeler des fonction ou des méthode ou coller des élement dans un template ne change rien à l'affaire.

je le dis et je le répêtes je ne critire en rein les systèmes de templates. je les utilises parfois (souvent) mais je regrète simplement que php ne me permette pas d'étandre facilement sa structure pour aller au dela comme le permettais il y a 10 ans déjà de le faire tcl.

aujourd'hui j'ai une bibliothèque de classes suffisement étofée pour ne plus à avoir à écrire de html pour faire des formulaires. ni dans un template ni dans le code.

et je pense que c'est ce que devrais fournir en standard php. en fonctionnel ou en objet.

A+JYT

17/08/2005, 08h08	#197
doof Membre actif Inscription : août 2003 Messages : 159 Détails du profil Informations forums : Inscription : août 2003 Messages : 159 Points : 160 Points : 160	GrandFather, je ne remet pas du tout en cause l'utilité d'un système de templates, j'en suis moi même un inconditionel, et parfaitement d'accord sur le fait que c'est indispensable pour travailler proprement dans un style modèle vue controleur (j'aime pas le mot framework, je m'y sent à l'étroit) J'insiste simplement sur le fait qu'utiliser php comme langage de template me semble plus judicieux qu'un autre pseudo langage, et aussi sur fait que le parseur de PHP se comporte déjà à la manière des templates. Tous les avantages que tu donnes plus haut se résolvent sans problème en utilisant PHP, il faut juste se faire une base objet pour encadrer tout ça bien évidement, je t'invite à regarder sérieusement le fonctionnement de Savant, qui de façon simple, n'a rien a envier à Smarty, tu y retrouvera tous les avantages que tu donnais plus haut (cadriciel, plugins, filtres...), sauf qu'ici le langage de template est php. La lecture de son code est d'ailleurs déconcertante de simplicité et instructive. Concernant l'abrévation du code, comme le souligne naholyr c'est effectivement le seul avantage que l'on pourait trouver avec un système de template à code auto généré, mais je le trouve bien maigre. Concernant les filtres pipés, on pourrait très bien arriver à quelquechose sensiblement similaire en php : Code : Sélectionner tout - Visualiser dans une fenêtre à part <?php $this->_o($exercice,'escape_xml_entities','capitalize', ...) ?> Et l'on évite donc le l'enfert LISP [instant poilu]Tu fais beaucoup de XML, tu devrais aimer ce qui est lourd et verbeux non ? je rigole hein [/instant poilu] Et sinon, juste un p'tit truc par rapport à l'exemple de code que tu donnes : PHP admet pour les boucles et conditions une syntaxe alternative : if: .... endif; foreach:....endforeach; ce qui est plus sympas dans un template que les accolades difficilement lisibles (on dirait d'ailleurs que cette syntaxe a été spécialement prévue pour les templates). Un nouvel avantage venu avec la sortie de php5 et de sa spl est la surcharge du foreach permetant de faire des bouclages simplement et de manière adaptée à la structure à représenter, je trouve ça idéal pour les templates.
	00

12/08/2005, 20h19	#183
doof Membre actif Inscription : août 2003 Messages : 159 Détails du profil Informations forums : Inscription : août 2003 Messages : 159 Points : 160 Points : 160	Ca reste néamoins un "cadriciel" de template, le mot "moteur" en ce sens reste subtile et à l'appréciation de chacuns. PHP est un moteur de templates en lui même, surement le meilleur, mais il n'a jammais eu de cadriciel clair, laissant plusieurs tentatives naitre, en oubliant ce qu'était une des forces principales de php à la base. Force est de constater qu'aucun n'arrive à la cheville de php, je défendais flexy dernièrement, mais je l'ai finalement abandonné, puisque, comme tous les autres, je me suis retrouvé à un moment limité. Les avantages que je lui trouvais à l'époque, avec l'arrivée de php5 n'en sont plus : la manipulation DOM se fait très bien avec l'extension DOM comprise de base dans php5, le filtrage automatique des variables, se gère facilement soit en __get(), soit en __set()... Et l'on dispose en plus de toute la puissance du langage php. Oui, j'ai changé d'école (j'ai eu une révélation : tout système de template alternatif est une perte de productivité, et même de bon sens ) et il fallait quand même que je l'avoue.
	00

12/08/2005, 20h53	#184
doof Membre actif Inscription : août 2003 Messages : 159 Détails du profil Informations forums : Inscription : août 2003 Messages : 159 Points : 160 Points : 160	Ca fait 5 ans que je perd mon temps avec des "moteurs de templates", dans le sens où avec chacuns, j'ai a un moment ou un autre dû lutter pour représenter quelquechose un tant soit peu légèrement complexe. Pour l'anectdote, j'avais toujours eu depuis le début un solution avec PHP. Mais là où je me fourvoyais : surtout "ne pas mélanger php avec du html", l'erreur de tous ces "systèmes" répercuté sur ma façon de voir les choses... Je maudit maintenant celui qui est à l'origine de ce mauvais tournant. Séparer présentation et logique métier ne signifie en rien séparer php/html, et utiliser un langage limité-hybride/html n'est certainement pas une solution interessante, il faudrait qu'elle amène au moins une possibilité nouvelle (ce que le seul sachant le faire était flexy : manipulation dom). Pour ma façon de séparer les choses, il n'y a rien de plus simple : je remplis un objet me servant de conteneur de variables à afficher (nommé $datas dans la plupart des cas), l'objet $view (template php/html le plus souvent) se charge de l'afficher à sa guise.
	00

16/08/2005, 11h24	#186
zax-tfh Membre éclairé Inscription : février 2003 Messages : 794 Détails du profil Informations personnelles : Âge : 30 Localisation : France, Meurthe et Moselle (Lorraine) Informations forums : Inscription : février 2003 Messages : 794 Points : 301 Points : 301	Absolument, par contre pour ton probleme de cache, c'est peut etre normal non ? si ton fichier de template faisait 2Ko, as tu pensé aussi que le cache une fois "templatisé" (donc que le moteur de tpl a fait son job en placant les données à l'interieur) beh les données placées auraient pu donner ces 4Ko supplémentaires ? Sinon pour ce qui est de bannir les tpl, je suis pour ^^ la syntaxe donnée juste au dessus est aussi simple, voire plus simple que celle d'un moteur de template. Faut juste que je reflechisse sur ses faiblesses à long terme sur des cas particuliers mais je ne pense pas en rencontrer
	00

16/08/2005, 11h27	#187
hugo123 Rédacteur Geek entrepreneur Inscription : novembre 2004 Messages : 1 087 Détails du profil Informations personnelles : Sexe : Localisation : France Informations professionnelles : Activité : Geek entrepreneur Informations forums : Inscription : novembre 2004 Messages : 1 087 Points : 2 128 Points : 2 128	Tu as justement pointé sur la différence zax-tfh. Smarty va créer des pages statiques (et c'est bien pourquoi elles sont plus lourdes que ton code php) qui ne seront pas recompilées a chaque fois. Donc la syntaxe évoqué plus haut n'est équivalente que pour la mise en page et la pseudo séparation du code et du html.
	00

16/08/2005, 11h33	#188
zax-tfh Membre éclairé Inscription : février 2003 Messages : 794 Détails du profil Informations personnelles : Âge : 30 Localisation : France, Meurthe et Moselle (Lorraine) Informations forums : Inscription : février 2003 Messages : 794 Points : 301 Points : 301	Oui donc après c'est à chacun de decider ce qu'il veut, soit il met en cache son contenu si le serveur n'est pas ultra puissant ou pour éviter moulet calcul si ce n'est pas nécessaire, soit il ne met pas en cache et donc gère le couple PHP/MySQL. Personnellement je suis sur un developpement de portail web (type CMS) et je vais mettre en place le cache de cette maniere : tout ce qui n'est pas strictement dynamique, gestion en cache comme pour les articles par exemple. Et lors de leur edition, suppression je régénere le cache. Comme ceci, il n'y a que du html qui est envoyé ce qui je pense doit alléger la requete. Car au final si on y reflechi : les données envoyées sont les memes : Technique php/mysql : requete->traitement du serveur->parsage des donnéées en html->envoi au client Technique avec cache : requete->traitement du serveur->parsage des donnéées en html->envoi au client Sauf que entre les deux techniques c'est le traitement du serveur qui va différer. Dans le premier : le tratement sera plus lourd sachant qu'il va devoir rapatrier toutes les données et les mettre en page. Dans la deuxieme méthode, il n'y aura qu'une éventuelle lecture de base de données pour savoir ou se trouve le fichier de cache et basta. Apres le reste est déja fait niveau mise en page et tout ça. Donc pour moi le mieux est de mettre en cache...ca n'engage que moi. ++
	00

16/08/2005, 12h09	#189
zax-tfh Membre éclairé Inscription : février 2003 Messages : 794 Détails du profil Informations personnelles : Âge : 30 Localisation : France, Meurthe et Moselle (Lorraine) Informations forums : Inscription : février 2003 Messages : 794 Points : 301 Points : 301	C'est là ou je me dis que la mise en cache telle qu'elle est gérée ne me plait pas... On lui donne une durée, mais qu'est-ce qui fait dire qu'au bout de tant de temps il faut régénérer le cache ? Pour moi on doit le refaire à partir du moment ou on change son contenu (cf mon exemple avec les articles)...M'enfin c'est mon point de vue, je pense que cela doit bien servir à moult applications. Mais en fait ça illustre ma vision globale de tout ça : pourquoi faire compliqué quand on peut faire simple ? Ces moteurs gèrent tellement de trucs qu'on ne sait meme pas si on l'exploite vraiment ou bien si c'est juste pour dire qu'on utilise un moteur de tpl et qu'en fait on n'en exploite que 2%. Au départ quand j'utilisais phplib, c'etait uniquement pour parser des variables (donc vraiment uniquement ce qui a été montré en code plus haut).... et je pense que tout le reste qui était géré par phplib ca ne me servait à rien mais devait bouffer de la ressource quand meme....donc inutile. Rien ne vaut un bon truc maison que l'on maitrise completement.
	00

16/08/2005, 13h40	#190
hugo123 Rédacteur Geek entrepreneur Inscription : novembre 2004 Messages : 1 087 Détails du profil Informations personnelles : Sexe : Localisation : France Informations professionnelles : Activité : Geek entrepreneur Informations forums : Inscription : novembre 2004 Messages : 1 087 Points : 2 128 Points : 2 128	Tout a fait, je te rejoins lorsque tu dis "Rien ne vaut un bon truc maison que l'on maitrise completement." Mais ce raisonnement vaut aussi bien pour le php. Tu maitrises aujourd'hui le php, donc tu t'en sors bien, mais avant ca tu as du lire la doc et tatonner. Les moteurs de templates, c'est pareil, il faut lire la doc et tester. Smarty permet d'utiliser une gestion de cache spécifique, il peut définir des parties dynamiques dans une page statique et bien d'autres choses. En plus dans la doc il y a tout un chapitre qui est dédié a ca. Ensuite chacun fait son choix comme l'a dit Poof, mais pour pouvoir faire un choix il faut le faire en connaissance de cause.
	00

16/08/2005, 13h44	#191
zax-tfh Membre éclairé Inscription : février 2003 Messages : 794 Détails du profil Informations personnelles : Âge : 30 Localisation : France, Meurthe et Moselle (Lorraine) Informations forums : Inscription : février 2003 Messages : 794 Points : 301 Points : 301	D'accord à 100%. Mais en fait ce qui est bien là c'est qu'on donne nos points de vue sans se bouffer le nez comme dans la plupart des forums, et ça c'est trop top car c'est une discution constructive (la premiere que j'apprecie autant je crois d'ailleurs ) et les personnes qui liront ce topic auront des avis qu'ils choisiront selon leurs besoins. Pour smarty, je ne le remet pas en question en fait. Juste que j'ai bien envie de faire ma mouture a moi ^^ Cela dit je pense fortement qu'il doit etre interressant, à voir comment tout le monde en parle.
	00

16/08/2005, 13h56	#192
hugo123 Rédacteur Geek entrepreneur Inscription : novembre 2004 Messages : 1 087 Détails du profil Informations personnelles : Sexe : Localisation : France Informations professionnelles : Activité : Geek entrepreneur Informations forums : Inscription : novembre 2004 Messages : 1 087 Points : 2 128 Points : 2 128	Je l'utilise depuis peu, avant j'avais mon propre système. Mais il n'était pas terrible et j'ai vraiment gagné en perf (et c'est plus facile a modifier aussi). Certains le disent lent par rapport a d'autres moteurs, mais je n'ai pas pu comparer. Par contre avec la gestion du cache, sur de grosses quantité de données, j'ai bcp gagné par rapport a des pages php sans moteurs. D'autres le jugent trop complexes, un designer web peut avoir du mal a éditer les templates. Je pense par contre que son intérêt, c'est d'éviter de refaire ce qui a déjà été fait. Faire son moteur a soi c'est possible, mais ca prend du temps, il faudra faire face a des pbs qui ont déjà été réglés par d'autre et le temps on ne l'a pas toujours. C'est aussi avec ce raisonnement que j'utilise les librairies PEAR a fond plutot que de faire du spécifique ^^ J'ai toujours une interface d'admin qui n'utilise pas smarty par contre. Ca me permet de comparer sur des pages qui affichent a peu près les mêmes données (gestion des news et affichage des news par exemple).
	00

16/08/2005, 18h13	#194
doof Membre actif Inscription : août 2003 Messages : 159 Détails du profil Informations forums : Inscription : août 2003 Messages : 159 Points : 160 Points : 160	Il est vrai que l'utilisation de <?php echo... ?> était une étape psychologique qui me rebutait, mais j'ai redécouvert un truc excellent depuis que j'utilise ce système : la coloration syntaxique ! Quel bonheur de voir les parties dynamiques de mon template directement colorées par mon éditeur ! Donc niveau lisibilité, même si c'est légèrement plus verbeux, je trouve au contraire qu'on y gagne. Je n'ai pas bien compris l'avantage de smarty pour l'histoire des entités HTML, en quoi étendre smarty par une fonction apportera "plus de souplesse" que de définir cette même fonction en php et tout simplement l'utiliser ? Même si tu nous montre que ça n'est pas si compliqué avec smarty, je ne vois pas l'avantage qu'apporte un moteur de template dans un ce spécifique. :
	00

16/08/2005, 20h56	#196
naholyr Membre régulier Inscription : décembre 2002 Messages : 89 Détails du profil Informations forums : Inscription : décembre 2002 Messages : 89 Points : 94 Points : 94	GrandFather pointe le doigt sur les deux seuls avantages indéniables des surcouches templates : - L'abbréviation pour les traitements de caractères ayant très à la présentation (la mise en capitale, l'htmlentitiesation, etc... font partie de la présentation et devraient donc idéalement être dans le template). - L'utilisation dans le cas d'XML où la syntaxe allégée est impossible. Enfin un bémol là-dessus : on peut tout-à-fait utiliser la syntaxe allégée il suffit de changer le prologue XML de <?xml ... ?> en <?='<?xml ... ?'.'>'?>. Si cette première ligne sera peu lisible le reste le sera un peu plus. Mais dans les deux cas il y a une contrainte. Ces deux points ne me suffisent pas, et j'avoue être ravi de voir le retour en arrière global opéré ces derniers temps.
	00

08/09/2005, 14h01	#200
sekaijin Expert Confirmé Sénior Urbaniste Inscription : juillet 2004 Messages : 2 113 Détails du profil Informations personnelles : Sexe : Âge : 49 Localisation : France, Yvelines (Île de France) Informations professionnelles : Activité : Urbaniste Secteur : Santé Informations forums : Inscription : juillet 2004 Messages : 2 113 Points : 5 030 Points : 5 030	mon propos n'est pas de dire que c'est mieux où moins bien. je note simplement que pour faire une appli web en php il faut connaitre minimum 2 langage. php et html et qu'à un moment ou un autre on mixe les deux. le fait de passer par un système de template ne fait qu'ajouter un language. php html et le language de template. et qu'au lieu de mixer php et html on mixe le langage de template et html. la solution que proposais tcl avait le mérite de ne plus proposer qu'un seul langage. quant à savoir comment on sépare le code de l'affichage aucune de ses trois approche ne le garantit. php + html n'implique pas necéssairement qu'on mélange le code métier avec le code d'affichage php + tpl + html ne garantit pas qu'on ne mettra pas de html dans le code metier. de même l'approche proposé par tcl ne garantit pas la séparation des couches. pour ma part je code php en objet et je sépare les couche comme suit Classes d'accès aux données Controleur d'accès au données (aux classes d'accès aux données) Classes métiers Controleur appllicatifs (Logique applicative) Classes de présentation (qui utilise ou pas un système de template) la couche présentation et assuré par les classes de présentation. aucune autre clase ne contient d'élément relatif à l'affichage. totalement écrite en php la séparation des couche est tout de même assurée. si elle utilise un moteur de template même topo. c'est bien l'architecture de programmation qui me garantie cette séparation pas l'usage d'un moteur de template. alors appeler des fonction ou des méthode ou coller des élement dans un template ne change rien à l'affaire. je le dis et je le répêtes je ne critire en rein les systèmes de templates. je les utilises parfois (souvent) mais je regrète simplement que php ne me permette pas d'étandre facilement sa structure pour aller au dela comme le permettais il y a 10 ans déjà de le faire tcl. aujourd'hui j'ai une bibliothèque de classes suffisement étofée pour ne plus à avoir à écrire de html pour faire des formulaires. ni dans un template ni dans le code. et je pense que c'est ce que devrais fournir en standard php. en fonctionnel ou en objet. A+JYT
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email