Le moteur TPLN est aussi bien utilisé de manière professionnelle que personnelle.
Au programme :
- greffon form> réécriture complète du greffon, la gestion des erreurs est faite par PHP
- greffon form> ajout de la méthode formSetDisplayMode() pour choisir l'endroit pour vos erreurs dans votre formulaire
- greffon form> ajout de la méthode imgControlWidth()
- greffon form> ajout de la méthode imgControlHeight()
- greffon form> ajout de la méthode Url(http, https , ftp)
- greffon form> amélioration ajout du paramètre facultatif addError()
- greffon form> amélioration de la méthode onlyDigit(), les flottants en deuxième paramètre
- greffon mail> ajout de la méthode MailConfirm() pour avoir une confirmation de lecture
Les caractéristiques de ce moteur sont :
- Simple d'utilisation et rapide
- Gestion des blocs multiples
- Gestion avancée de cache
- Interfaçage avec PEAR DB assurant une compatibilité avec 11 SGBDR (MySQL, MS SQL Server, Oracle, SQLite ...)
- Gestion de la pagination automatique et personnalisable
- Plugin Form pour contrôler vos formulaires de manière très simple
- Plugin Mail, gestion d'envoi d'email avec gestion des pièces jointes
- Architecture de greffon ouverte
- Sa documentation claire
De nombreux exemples et réalisations sont présents en ligne.
Aller plus loin
- Website (3 clics)
- Exemples en ligne (3 clics)
# Quel intérêt ?
Posté par Nicolas (site web personnel) . Évalué à 2.
[^] # Re: Quel intérêt ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
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 BAud (site web personnel) . Évalué à 5.
ç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 (site web personnel) . Évalué à 1.
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 (site web personnel, Mastodon) . Évalué à 2.
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 . Évalué à 3.
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 (site web personnel, Mastodon) . Évalué à 3.
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 . Évalué à 1.
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 . Évalué à 3.
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 :
[^] # Re: Quel intérêt ?
Posté par PLuG . Évalué à 1.
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 . Évalué à 2.
> 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 . Évalué à 2.
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 (site web personnel, Mastodon) . Évalué à 1.
<?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..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.