Quel intérêt ?

• [^]Re: Quel intérêt ?

  Posté par Laurent J (page perso, ) le 03/08/2006 à 08:29. (lien). Évalué à 4.

  vous permettant de séparer la présentation de la logique applicative.

  
  
  M'enfin là, ça me fait doucement rigoler quand même, quand on lit que TPLN propose un "nterfaçage avec PEAR DB" ou encore pluginmail.. Je me demande bien où est alors cette séparation...
  
  L'objectif d'un vrai moteur de template est de justement de ne pas s'occuper de ça. Son véritable rôle, c'est juste de reçevoir des données (c'est pas à lui d'aller les chercher ou de les envoyer je ne sais où), et de les mettre en forme selon les directives indiquées dans le fichier de template. Point final.
  
  Bref, à mon sens, TPLN ici n'est pas un pur moteur de template...
  
  
  Sinon, je n'aime pas ces moteurs de template avec lesquels il faut faire les boucles en php. Je prefère ceux où on indique tout dans le template : ça évite
  
  1) d'avoir à regarder deux fichier à la fois pour comprendre la logique de génération du code final
  2) d'avoir à répéter ce code PHP qui fait la boucle à chaque fois que l'on utilise le template en plusieurs endroits du programme.

• [^]Re: Quel intérêt ?

  Posté par baud123 (Jabber id, page perso, ) le 03/08/2006 à 09:34. (lien). Évalué à 5.

  A quoi sert un moteur de template ? Quel est en est l'intérêt ?
  ça sert à quoi que je wikipédifie les articles à chaque fois, s'il y en a qui ne s'en rendent pas compte ?
  bwalé, je te donne le lien : http://fr.wikipedia.org/wiki/Template

  • [^]Re: Quel intérêt ?

    Posté par Nicolas (page perso, ) le 03/08/2006 à 13:23. (lien). Évalué à 1.

    Je ne connaissais pas précisément cette description d'un moteur de template mais je sais grossièrement ce qu'est un moteur de template.
    
    Je partage un peu l'avis de Laurent: TPLN ne remplit pas son rôle de moteur de template puisqu'il ne se contente pas d'afficher les données qu'il reçoit.
    
    Je reste septique sur l'intérêt de ce genre d'usine à gaz. Pourquoi ne pas simplement utiliser un template php ?
    
    Pendant un moment la mode a été aux moteurs de templates. Chacun avait le sien. Le but était de séparer forme et présentation. Mais ceci était avant l'avénement des feuilles de styles css. Le template ne sert plus qu'a séparé le code php du code html ce qui est déjà très bien.
    
    Je reste avec mes jolis templates php et je laisse les développeurs de moteur de templates réinventer la roue.

    • [^]Re: Quel intérêt ?

      Posté par Laurent J (page perso, ) le 03/08/2006 à 16:03. (lien). Évalué à 2.

      personnellement, je prefère la syntaxe proposée par certains moteurs de template, tout simplement parce que :
      
      1) ça facilite l'écriture et la lisibilité du template. pour faire un echo, pas besoin de faire des <?php echo $truc;?> de partout (et il y en a beaucoup dans un template des echo !), un simple {$truc} suffit dans smarty par ex. la syntaxe du template peut aussi inclure des fonctionnalités que ne fournit pas php. Exemple, dans jTpl ( http://www.jelix.org/articles/manuel/templates ), {@truc@} permet de récupérer et afficher une chaine localisée (dont la clé est truc). Pas besoin de faire à chaque fois un <?php echo getlocale('truc');?> ou autre..
      
      Et je ne parle pas des facilités de formatages que peut apporter un moteur de template.
      
      2) ça limite les tentations d'y faire des traitements métiers (surtout dans le cadre d'un framework). La syntaxe limitée (en théorie) des templates ne permet de faire que de l'affichage/formatage, et rien d'autre. Ce qui est le but recherché
      
      3) le moteur peut aussi avoir une fonctionnalité de cache pour le contenu généré, ce qui peut être interressant.
      
      4) Pour les arguments sur la contre-performance des moteurs de templates, ce n'est pas forcément valable quand le moteur transforme le template utilisé en fichier PHP et le met en cache (comme le font smarty ou jtpl par ex). Les différences de perf sont alors minimes (puisqu'alors le moteur se contente de faire un include PHP du cache)
      
      5) La possibilité pour l'application d'accepter des templates "exterieurs" (uploadés par les utilisateurs par exemple, pour personnaliser un blog sur un site d'hebergement de blog par exemple, ou de personnaliser le rendu d'un document généré par l'appli) : comme le langage du template est limité et en theorie moins complexe pour php, il y a beaucoup moins de risque au niveau sécu pour l'appli, et c'est plus facile pour l'utilisateur.
      
      Bon aprés, l'interet que l'on voit dans un moteur de template, c'est une histoire de goût, et surtout selon les besoins pour le développement de l'appli.
      
      Note à propos de CSS : on ne fait pas tout avec CSS, surtout avec les implementations aléatoires dans les navigateurs. Il faut attendre au moins CSS3 pour dire que CSS est suffisement souple pour pouvoir styler comme on veut n'importe quel document XML/XHTML (et encore..). Quand on veut changer de "layout", d'organisation des éléments dans une page, il arrive qu'il faille modifier le html. Et si en plus l'auteur n'a pas mis suffisement de section (div), d'ID ou de class, ça devient complexe.. Bref, les templates (PHP ou autre) gardent leur interet.

      • [^]Re: (non)intérêt des technos tierces pour la lisibilité des "templates"

        Posté par Amaury () le 03/08/2006 à 17:02. (lien). Évalué à 3.

        Les solutions de templates ont des avantages certes, mais sans doutes pas pour faciliter "l'écriture et la lisibilité du template". Il est possible d'utiliser des templates HTML/PHP natif très lisibles. PHP dispose en effet de fonctions sympathiques qui invalident les deux exemples cités.
        
        Pour faire un echo, pas besoin de faire des <?php echo $truc;?>
        Un simple <?=$truc?> suffit en PHP. [1]
        Pas besoin de faire à chaque fois un <?php echo getlocale('truc');?>
        Un simple <?=_('truc')?> suffit en PHP. [2]
        
        Les templates n'apportent donc pas grand chose _sur ce point_, si ce n'est une syntaxe supplémentaire à maîtriser.
        
        [1] http://fr2.php.net/manual/en/function.echo.php
        [2] http://fr2.php.net/manual/en/function.gettext.php

        • [^]Re: (non)intérêt des technos tierces pour la lisibilité des "templates"

          Posté par Laurent J (page perso, ) le 03/08/2006 à 21:04. (lien). Évalué à 3.

          sauf que ta notation necessite de configurer php avec un short_open_tag = on, et qu'elle est de ce fait déconseillé par les développeurs même de php :
          
          

          
          ; NOTE: Using short tags should be avoided when developing applications or
          ; libraries that are meant for redistribution, or deployment on PHP
          ; servers which are not under your control, because short tags may not
          ; be supported on the target server. For portable, redistributable code,
          ; be sure not to use short tags.
          

          
          
          De plus, gettext d'une part ça suxor (c'est mon avis et je le partage, je préfère les systèmes à clé/fichier properties plutôt que ce truc lourd et qui rend la maintenance difficile), et d'autre part, surtout, n'est pas toujours utilisable puisque pas installé par défaut avec php...

          • [^]Re: (non)intérêt des technos tierces pour la lisibilité des "templates"

            Posté par Amaury () le 04/08/2006 à 16:11. (lien). Évalué à 1.

            Cette notation abrégée n'est déconseillée que pour se garantir que le code soit universellement déployable, y compris sur les plate-formes où la configuration du système hôte n'est pas possible.
            Cette restriction concerne donc exclusivement les personnes disposant d'un bout d'espace disque virtuel chez un hébergeur ayant explicitement désactivé cette fonction (elle est activée par défaut) et n'ayant pas moyen d'activer cette option.
            Il ne s'agit donc pas d'une faille de sécurité, mais d'une précaution à prendre si l'on développe une application destinée à être diffusée largement.
            
            Par ailleurs, à ma connaissance, la majorité des distributions incluent le support gettext dans PHP. Et d'une part gettext ça roxore (c'est mon avis et je le partage, je préfère les systèmes standards et disposant de moults éditeurs plutôt que de devoir fournir directement des fichiers PHP à mes traducteurs, pour qui le PHP est un stupéfiant), et d'autre part, surtout, est utilisable "out of the box" avec toutes les distributions que j'ai eu à utiliser.
            
            Je trouve enfin amusant de critiquer l'utilisation de fonctions standards PHP (notation abrégée, gettext) au prétexte qu'elles ne seraient pas si standard que cela, pour promouvoir des systèmes de templates totalement externes au langage et pas standards du tout.

• [^]Re: Quel intérêt ?

  Posté par Laurent GUEDON (page perso, ) le 04/08/2006 à 06:19. (lien). Évalué à 3.

  J'ajouterai même : "A quoi sert un moteur de template ? PHP EST lui même un moteur de template."....
  
  Qu'on ne me réponde pas que c'est pour avoir un langage plus simple d'accès... Suffit de voir Smarty : bientôt il faudra un langage de template pour Smarty.
  
  Il n'y a pas que moi qui le pense :
  

  Rasmus Lerdorf : PHP is a templating engine by itself. Adding another templating engine on top of it just doesn't make sense. The only situation where it makes sense, is when you don't trust the template to contain nice behaving code.

  • [^]Re: Quel intérêt ?

    Posté par PLuG () le 04/08/2006 à 14:33. (lien). Évalué à 1.

    C'est assez vrai .... sauf que la séparation de la partie HTML/CSS (faite par un web designer) de la partie code applicatif (faite par un développeur) apporte quand meme beaucoup de clarté pour ces 2 sous ensembles.
    Le code PHP est propre et uniquement applicatif, pas de génération de HTML dedans.
    Le code HTML est propre et pas alourdit par des bouts de PHP.
    
    Avec un moteur de template comme Pear/Flexy, le code HTML+CSS+Flexy est editable avec les editeurs HTML du marché, ... ça simplifie quand même pas mal le boulot du webdesigner.
    
    Donc oui, PHP est *deja* un moteur de template, et il est bien parcequ'il est souple. Mais la souplesse conduit les gens à pondre du code non maintenable. Forcer les gens a travailler proprement c'est utile dans une organisation même si cela parait techniquement abérant (2 moteurs de template l'un sur l'autre).

    • [^]Re: Quel intérêt ?

      Posté par Amaury () le 04/08/2006 à 16:08. (lien). Évalué à 2.

      > la séparation de la partie HTML/CSS (faite par un web designer) de la
      > partie code applicatif (faite par un développeur) apporte quand meme
      > beaucoup de clarté pour ces 2 sous ensembles.
      
      Le problème tel que je le conçois est que l'utilisation de templates peut très vite rendre le code HTML illisible :
      - soit en découpant le code HTML en multiples fichiers, inclus par le moteur ce qui fait perdre la vue d'ensemble, mais permet de ne pas mélanger application / présentation ;
      - soit en conservant un seul template qui se retrouve à l'usage remplit de code ésotérique et propriétaire (syntaxe Smarty, SPIP...)
      
      Personnellement la lisibilité du template me parait primordiale, c'est pourquoi j'adopte généralement la deuxième solution, en utilisant la syntaxe PHP abrégée, qui permet justement de ne pas encombrer le template de fonctions, boucles et autre code rendant difficile la compréhension globale du template.
      Cela évite également de devoir installer un logiciel de templates tiers (avec les problèmes de sécurité qui en découlent), d'apprendre la syntaxte spécifique du moteur de template et, parfois, de devoir torturer le moteur de template lorsque l'on veut lui faire faire quelque chose qui n'est pas dans la philosophie dudit moteur.
      
      Ceci dit, je comprends tout à fait que l'on affectionne les moteurs de templates; en revanche l'argument qui consiste à dire "point de séaration code/présentation sans moteurs de templates" me semble erroné.

      • [^]Re: Quel intérêt ?

        Posté par Moonz () le 04/08/2006 à 19:31. (lien). Évalué à 2.

        >"point de séaration code/présentation sans moteurs de templates" me semble erroné.
        
        Heu... comment tu fais, disons, pour afficher une liste de news venant d'une base MySQL sans template et en séparant code/présentation ?
        De plus, dire que <?=$var?> et {$var}, c'est pareil, pas la peine d'utuiliser un système de template, c'est bien joli, mais comment tu fais pour les boucles ? les if/else ?
        
        Avoue quand même que un {block news}<a href="news.php?id={news.id}">{new.title}</a><br/>{/block} est plus simple et plus "élégant" que
        <?php while($news = mysql_fetch_assoc($query)) { ?><a href="news.php?id=<?=$news["id"]?>"><?=$news["title"]?></a><br/><?php } ?>

        • [^]Re: Quel intérêt ?

          Posté par Laurent J (page perso, ) le 06/08/2006 à 18:05. (lien). Évalué à 1.

          Moonz, d'accord avec toi.. mais ton deuxième exemple est à corriger, parce que là, tu n'as pas du tout une séparation presentation/métier ;-)
          
          <?php foreach($listenew as $news) { ?><a href="news.php?id=<?=$news["id"]?>"><?=$news["title"]?><?php } ?>
          
          Ici tu as une vraie séparation ;-), la liste des news étant récupéré par l'objet utilisateur du template (on s'en fout comment), et donné au moteur de template sous le nom listenews..