Discussion :

[Théolude]

Oui tu as raison à propos de "ma" vision des templates, ce n'est pas une vérité absolue et intangible, mais de mon point de vue et par rapport à l'usage que j'en conçois c'est leur raison d'être... Je n'ai vraiment jamais compris l'intérêt de la démarche de Smarty. Je veux bien que tu me l'expliques

En ce qui concerne la syntaxe je suis curieux quand même, pourrais tu me montrer les différents fichiers et leur contenu pour faire une page assez simple avec une petite boucle dedans (genre un tableau avec des lignes à afficher).

Théo

[metagoto]

Twig est très fortement inspiré des templates du framework python Django
http://docs.djangoproject.com/
La syntaxe des templates est très similaire. On y retrouve la notion "d'héritage", les blocks etc.

Pour Twig, les templates sont parsées et transformées en fichiers php. Ces fichiers sont mis en cache.

[Thierry B.]

Oui tu as raison à propos de "ma" vision des templates, ce n'est pas une vérité absolue et intangible, mais de mon point de vue et par rapport à l'usage que j'en conçois c'est leur raison d'être... Je n'ai vraiment jamais compris l'intérêt de la démarche de Smarty. Je veux bien que tu me l'expliques

En ce qui concerne la syntaxe je suis curieux quand même, pourrais tu me montrer les différents fichiers et leur contenu pour faire une page assez simple avec une petite boucle dedans (genre un tableau avec des lignes à afficher).

Théo

Pour la syntaxe tu peux voir sur cette page par exemple : http://docs.djangoproject.com/en/1.2...pics-templates ou sur le site de Twig, c'est assez bien documenté.

Effectivement le mécanisme d'héritage et de surcharge de blocks et très pratique et permet d'avoir une arborescence de templates très propre et lisible. Mais on parle beaucoup de template et on en oublie le moteur : le gros point fort de Twig c'est son API : simple, moderne, extensible, full OO. Elle s'intégère parfaitement avec notre nouveau socle interne (contrairement à smarty qui fait son âge, et ce n'est malheureusement pas la version 3 qui va changer la donne).

[sekaijin]

A priori je n'aime pas mais alors pas du tout, c'est le contraire selon moi de la philosophie template, dans la droite ligne de l'hérésie ignitiée par Smarty...

Un template ça se doit de ne pas comporter une seule règle syntaxique, d'avoir un balisage normé XML pour être intégré de manière invisible dans des documents XHTML valides, et de permettre à toutes les personnes travaillant sur un projet (développeur et graphistes) de se retrouver à l'aise avec leurs outils sans que l'un déborde sur le travail de l'autre.

Le produit à l'air propre, bien conçu dans son architecture, mais son utilisation et sa syntaxe me parait lourdingue à souhait. Pourquoi couper les cheveux en 4 quand on peut les couper en 185 ?

My two pences...

Tu penche donc vers des truc comme TAL
http://phptal.org/
http://www.zope.org/Documentation/Bo...dition/ZPT.stx

A+JYT

[Théolude]

Tu penche donc vers des truc comme TAL
http://phptal.org/
http://www.zope.org/Documentation/Bo...dition/ZPT.stx

A+JYT

Ca me plait déjà beaucoup plus dans la forme du template...
Je vais regarder en détail l'utilisation de la classe, ses méthodes, etc. mais clairement ça correspond beaucoup plus à ce que je définis comme étant un moteur de templates.

Merci du tuyau !

Théo

[gtraxx]

Pourquoi tous le monde casse du sucre sur le dos de smarty, personnellement je l'utilise depuis plusieurs année et participe activement à son avancement (rapport de bug, amélioration, astuces, etc..).
Depuis le passage à la version 3, on constate une véritable amélioration du moteur ainsi qu'un enrichissement du langage.
La syntaxe peut être difficile à appréhender au premier abord quoi que smarty 3 simplifie certaine chose, et accentue sur d'autres.
bref Il n'y à pas de mauvais moteur (bon si peut être) mais de mauvais utilisateur.
Personnellement j'adore sa syntaxe et je suis allergique à zend_view qui plus est je n'utilise pas le zend framework mais mon framework perso.
Mais je trouve le moteur de template de Fabien Potencier (que je salue au passage) intéressant, je vais m'y pencher pour le plaisir.
N'oubliez pas dans chaque moteur de template un développeur ou designer y trouve sont compte

[sekaijin]

je ne pense pas qu'on case du sucre simplement il n'est pas parfait comme tous les systèmes de templates.

le premier point qui est soit une bien fait soit un inconvénient le système de cache. c'est vrai pour tous les moteur de templates fonctionnant avec un cache.
- Soit on utilise le moteur pour faire un site genre joomla, spip etc et les pages produite sont relativement statiques (un article ne change pas tous le temps) et un système de cache est le bien venu pour éviter de refaire tous à chaque fois qu'on appelle une même page.
- Soit on fait une application très dynamique où chaque appel d'une action (url) génère un contenu très différent et dans ce cas le cache est un handicap. mettre en cache un truc qui à coup quasi sur ne sera jamais utilisé est inutile.

donc Comparé à ets dont la syntaxe et semblable à smarty l'un est préférable pour les applications très dynamique l'autre pour les sites de type cms.

l'approche sémantique de Smarty et de bien d'autre n'est pas non plus de très bonne augure.
à moins d'avoir un outil de design qui en tienne compte l'édition d'un template smarty se heurte à la déstructuration du langage hôte (HTML)
par exemple les balises smarty place entre un tbody et un tr pour faire une boucle se retrouve éjecté de là par et placé avant tant par le navigateur (si on ouvre le template comme une page html) que par les éditeur qui restructure le code conformément au w3c
ce n'est donc pas là tant le langage qui est en cause mais la façon qui a été choisie pour l'intégrer au html c'est particulièrement vrai lorsqu'on utilise smarty pour produire du XML.

par contre de nombreux designer le connaissent et savent le conserver dans leur outil d'édition même s'ils ne savent pas précisément comment il est utilisé.

Comparé à des approches par attributs ou ajouts XML smarty et ceux qui utilisent la même approche sont loin derrière.

le langage en lui même comme pour tout moteur cherche à concilier l'inconciliable. la simplicité et la richesse fonctionnelle. on en arrive parfois à avoir des templates qui sont à eux seul de véritable programme.
du coup on perd l'intérêt d'un moteur.
Smarty ce ce côté et tout aussi critiquable. ont peut lui demander beaucoup jusqu'à le dénaturer la syntaxe est simple au premier abord pas toujours très cohérente mais abordable. comme souvent pour faire des chose un peu évolué ça devient lourd.
ici lorsque la complexité deviens importante il est à se demander si un moteur est encore de bon augure.

il y a bien d'autre choses à dire.

je ne pense pas qu'il y ai UN bon système. je pense qu'il faut surtout avant de la choisir se poser les bonne question
Quelle est la population visé ? Quels sont les buts recherchés ? Où en est la connaissance (a-t-on la compétence) ? Qu'est-il le plus opportun pour l'utilisation cible ? quels sont les outils ? quid de la pérennité de la solution ? etc.

c'est en se posant les bonne question dans chaque projet qu'on arrive à choisir les bons outils.

A+JYT

[gtraxx]

Merci excellente précisions
Je tiens tout de même à signaler que pour les partie dynamique il existe dans smarty 3 la fonction nocache sans parler des 50 autres ajoutés
C'est vrai que pour un CMS il tient bien la route, je l'ai intégrer dans mon CMS connu sous le nom de Magix CMS.
chaque moteur à des faiblesses, tous le monde y trouve son compte puis c'est une question de gout, expériences d'utilisation.
Pour ce qui est de la validité w3c, j'ai fais une adaptation du moteur et pousse un maximum dans les version en cours (je ne suis que contributeur).
Bonne soirée à tous

[FrontLine]

La définition d'un bon système de template passe avant tout par définir ses besoins.

De mon coté je ne cherche qu'à séparer l'application et son interface pour pouvoir changer facilement de design ou importer une brique dans un autre site (gestionnaire d'articles, formulaire d'inscription, formulaire de connexion, ... par exemple).

Du coup devoir supporter un pseudo code c'est du boulot pour rien autant pour moi que pour la graphiste avec qui je travaille.

Du moment que les graphistes comprennent que le bout de code commence par <?php et se termine par ?> et qu'il ne faut surtout pas toucher ce qu'il y a entre ses balises ils comprennent aussi vite qu'un pseudo code.

Au cas où je vérifie derrière cela ne me prend que quelques minutes. Au passage les graphistes apprennent au fur et à mesure la syntaxe de PHP ce qui leur est bénéfique.

Si c'est trop complexe j'intègre moi même le code PHP.

Cela ne coûte pas plus cher qu'un serveur supplémentaire nécessaire à cause d'un gestionnaire de template qui alourdit le site en parsant à profusion un pseudo code.

Je parle bien évidement dans la configuration de travail qu'on a dans ma société.

Là ça fait 5 jours que je cherche un système de template pas trop bourrin qui permette cela et je n'en trouve pas. (il doit y en avoir c'est sûr).

Je vais regarder Twig et Dwoo, sinon je me demande si je ne vais pas le faire moi même en utilisant buffer+include ou eval mais l'une comme l'autre ce n'est pas très propre je trouve.

buffer+include dans le cas d'une boucle ce n'est pas top du tout.
eval ... is evil

[sibelmoch]

Pour ma part j'utilise Smarty on m'a appris en cours à l'utiliser mais je me suis aperçu que ce que j'ai appris n'est rien à côté des possibilités que l'on a avec ce générateur de templates. J'accroche bien à son fonctionnement même si parfois certains éléments ne sont pas faciles à implémenter l'ensemble reste vraiment complet pour ceux qui serait contre Smarty ou même ceux qui ne le sont pas il y a un article intéressant sur les raisons de ne pas utiliser Smarty : http://www.m4d3l-network.com/develop...-non-a-smarty/

Bonne lecture à vous

[gtraxx]

Cette article est un peu vieux, depuis smarty 3 est sorti en version final.
L'approche est tout à fait différente et beaucoup mieux que smarty 2, je pense que tout le monde trouve son bonheur