Affichage des résultats du sondage: Quel système de template utilisez/utiliseriez - vous ?

Votants
145. Vous ne pouvez pas participer à ce sondage.
  • PHPLib

    40 27,59%
  • VTemplate

    5 3,45%
  • Smarty

    81 55,86%
  • ModeliXe

    10 6,90%
  • PowerTemplate

    1 0,69%
  • PHPTemplate

    5 3,45%
  • Xtemplates

    2 1,38%
  • EcTemplate

    0 0%
  • UltraTemplate

    0 0%
  • Itemplate

    0 0%
  • Quick Template

    1 0,69%
  • YATS

    0 0%
+ Répondre à la discussion
Page 10 sur 14 PremièrePremière ... 67891011121314 DernièreDernière
Affichage des résultats 181 à 200 sur 271
  1. #181
    Membre habitué
    Inscrit en
    décembre 2002
    Messages
    89
    Détails du profil
    Informations forums :
    Inscription : décembre 2002
    Messages : 89
    Points : 102
    Points
    102

    Par défaut

    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.

  2. #182
    Candidat au titre de Membre du Club
    Inscrit en
    décembre 2003
    Messages
    17
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 17
    Points : 10
    Points
    10

    Par défaut

    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

  3. #183
    Membre confirmé
    Avatar de doof
    Inscrit en
    août 2003
    Messages
    159
    Détails du profil
    Informations forums :
    Inscription : août 2003
    Messages : 159
    Points : 270
    Points
    270

    Par défaut

    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.

  4. #184
    Membre confirmé
    Avatar de doof
    Inscrit en
    août 2003
    Messages
    159
    Détails du profil
    Informations forums :
    Inscription : août 2003
    Messages : 159
    Points : 270
    Points
    270

    Par défaut

    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.

  5. #185
    Membre habitué
    Inscrit en
    décembre 2002
    Messages
    89
    Détails du profil
    Informations forums :
    Inscription : décembre 2002
    Messages : 89
    Points : 102
    Points
    102

    Par défaut

    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 :
    1
    2
    3
    <html>
    ...
    <h1>Bienvenue <?=$pseudo?></h1>
    metier.php
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    <?php
     
    $db = new DB;
    $res = $db->query(...);
    ...
    $pseudo = $row->pseudo;
     
    ?>
    index.php
    Code :
    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 :
    1
    2
    3
    <html>
    ...
    <h1>Bienvenue {pseudo}</h1>
    metier.php
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    <?php
     
    $db = new DB;
    $res = $db->query(...);
    ...
    $pseudo = $row->pseudo;
     
    ?>
    index.php
    Code :
    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...

  6. #186
    Membre éclairé
    Profil pro
    Inscrit en
    février 2003
    Messages
    824
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : février 2003
    Messages : 824
    Points : 323
    Points
    323

    Par défaut

    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

  7. #187
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    novembre 2004
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 215
    Points : 2 377
    Points
    2 377

    Par défaut

    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.

  8. #188
    Membre éclairé
    Profil pro
    Inscrit en
    février 2003
    Messages
    824
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : février 2003
    Messages : 824
    Points : 323
    Points
    323

    Par défaut

    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.
    ++

  9. #189
    Membre éclairé
    Profil pro
    Inscrit en
    février 2003
    Messages
    824
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : février 2003
    Messages : 824
    Points : 323
    Points
    323

    Par défaut

    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.

  10. #190
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    novembre 2004
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 215
    Points : 2 377
    Points
    2 377

    Par défaut

    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.

  11. #191
    Membre éclairé
    Profil pro
    Inscrit en
    février 2003
    Messages
    824
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : février 2003
    Messages : 824
    Points : 323
    Points
    323

    Par défaut

    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.

  12. #192
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    novembre 2004
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 215
    Points : 2 377
    Points
    2 377

    Par défaut

    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).

  13. #193
    Expert Confirmé Sénior
    Avatar de GrandFather
    Inscrit en
    mai 2004
    Messages
    4 566
    Détails du profil
    Informations personnelles :
    Âge : 45

    Informations forums :
    Inscription : mai 2004
    Messages : 4 566
    Points : 6 909
    Points
    6 909

    Par défaut

    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 :
    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 :
    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).
    FAQ XML
    ------------
    « Le moyen le plus sûr de cacher aux autres les limites de son savoir est de ne jamais les dépasser »
    Giacomo Leopardi

  14. #194
    Membre confirmé
    Avatar de doof
    Inscrit en
    août 2003
    Messages
    159
    Détails du profil
    Informations forums :
    Inscription : août 2003
    Messages : 159
    Points : 270
    Points
    270

    Par défaut

    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. :

  15. #195
    Expert Confirmé Sénior
    Avatar de GrandFather
    Inscrit en
    mai 2004
    Messages
    4 566
    Détails du profil
    Informations personnelles :
    Âge : 45

    Informations forums :
    Inscription : mai 2004
    Messages : 4 566
    Points : 6 909
    Points
    6 909

    Par défaut

    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 :
    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 :
    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 :
      {$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.
    FAQ XML
    ------------
    « Le moyen le plus sûr de cacher aux autres les limites de son savoir est de ne jamais les dépasser »
    Giacomo Leopardi

  16. #196
    Membre habitué
    Inscrit en
    décembre 2002
    Messages
    89
    Détails du profil
    Informations forums :
    Inscription : décembre 2002
    Messages : 89
    Points : 102
    Points
    102

    Par défaut

    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.

  17. #197
    Membre confirmé
    Avatar de doof
    Inscrit en
    août 2003
    Messages
    159
    Détails du profil
    Informations forums :
    Inscription : août 2003
    Messages : 159
    Points : 270
    Points
    270

    Par défaut

    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 :
    <?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.

  18. #198
    Expert Confirmé Sénior
    Avatar de GrandFather
    Inscrit en
    mai 2004
    Messages
    4 566
    Détails du profil
    Informations personnelles :
    Âge : 45

    Informations forums :
    Inscription : mai 2004
    Messages : 4 566
    Points : 6 909
    Points
    6 909

    Par défaut

    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 :
    <?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]
    FAQ XML
    ------------
    « Le moyen le plus sûr de cacher aux autres les limites de son savoir est de ne jamais les dépasser »
    Giacomo Leopardi

  19. #199
    Expert Confirmé Sénior
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 229
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 229
    Points : 6 948
    Points
    6 948

    Par défaut

    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 :
    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 :
    echo "<div style=\"bacground-image('monimage.gif')\">truc</div>";
    devient
    Code :
    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

  20. #200
    Expert Confirmé Sénior
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 229
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 229
    Points : 6 948
    Points
    6 948

    Par défaut

    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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •