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

[Kioob]

Perso j'ai également été séduit par la syntaxe de Flexy, et ai ajouté à peu pres la même chose à mon petit moteur perso. Je suis encore très loin d'obtenir le même résultat (ce n'est pas un "vrai" parseur html/xml que j'utilise), mais les fonctions que j'obtiens sont emplement suffisantes pour mon utilisation.

L'utilisation directe du balisage html est vraiment une bonne idée, mais ne convient pas à tout (je pense entre autre aux else / elseif, et multi-actions assossiées à une balise). Je ne pense pas que flexy propose ces syntaxes, mais ca pourrait donner :

Code :

1
2
<balise flexy:if="toto">kdjkdsjfsldkfjsj</balise>
<balise flexy:else="toto">kdjkdsjfsldkfjsj</balise>

Code :

<balise flexy:if="admin" flexy:foreach="bidule,row" >kdjkdsjfsldkfjsj</balise>

Ce n'est que dans ce genre de cas que je préfère conserver une structuration "classique", avec des balises du genre {if:toto} {else:} {end:}.

[doof]

Un else est facilement faisable en utilisant un !

Code :

1
2
<balise flexy:if="toto">kdjkdsjfsldkfjsj</balise>
<balise flexy:if="!toto">kdjkdsjfsldkfjsj</balise>

Là ou ca se complique, c'est dans l'utilisation d'un if/elsif/elsif, mais grace aux méthodes, on peut aisement reproduire un switch :

Code :

1
2
3
<balise flexy:if="cond(choix,#show1#)">kdjkdsjfsldkfjsj</balise>
<balise flexy:if="cond(choix,#show2#)">kdjkdsjfsldkfjsj</balise>
<balise flexy:if="cond(choix,#show3#)">kdjkdsjfsldkfjsj</balise>

En definissant une simple méthode :

Code :

1
2
3
4
function cond($var, $str)
{
	return $var == $str;
}

(si ca peut t'inspirer )

[Kioob]

On peut reproduire le meme résultat, mais à mon avis Flexy ne va pas traduire ça par un if/else, mais bien par 2 tests... et je trouve cela domage.

Je préférerais encore un flexy:else, même si je ne trouve pas ça très "lisible"



PS : non, là dessus ça ne m'inspire pas du tout

[JEDI_BC]

Envoyé par naholyr

- Parce que {var} c'est plus rapide que <?=$var;?>, et que ça peut faire la différence.

Charger un template et le parser serais plus rapide que de mettre un <? echo $var;?> ?????

[genova]

Je dois surement être un martien, mais personnelement je suis acro du système PHPLib J'ai recodé un système de template basé sur PHPLib pour mon forum, en implementant quelques options suplémentaires comme des conditions (IF, ELSE, ELSEIF, IFEXIST) histoire de pouvoire rendre les templates encore plus indépendant du code PHP, et quelques accès a des variables du parseur, comme les variables des boucles des bloques par exemple ($i_0, $i_1, etc...). personnelement ce que j'aime beaucoup sur le syst-me PHPLib c'est le côté template, car il est on ne peut plus simple à utiliser, modifier, etc...

Et pour un forum c'est très important pour que n'importe qui puisse faire u ntemplate sans se taper la syntaxe des autres systèmes de templates. Ce que je reproche a pas mal de systèùes de templates, genre smarty, c'est que la syntaxe du template est très phpiser, et personnelement je pesne qu'un template est fait pour séparer le code PHP et HTML en priorité, et non pas pour séparer la page en code PHP et PHP/HTML hybride
Mais bon après chacun ses gouts, tout dépend de l'utilisation et de l'application programmée

[naholyr]

Envoyé par JEDI_BC

Charger un template et le parser serais plus rapide que de mettre un <? echo $var;?> ?????

Non, je pense plutot à l'échange développeur/designer.
Le développeur va indiquer au designer (ou l'inverse) quelles variables doivent être incluses dans le modèle. Taper {var} au lieu de <?=$var;?> permet:
- d'aller plus vite.
- de minimiser les possibilités d'erreur à la lecture et/ou à la lecture du modèle.
- d'avoir un élément bien plus lisible (même un développeur chevronné lira plus vite {var} que <?=$var;?>).

C'est le seul argument vraiment valable que je me verrais opposer à l'article traitant des templates comme d'une surcouche inutile à php (cf post 2 pages plus tot je crois).

[chtiboss]

Salut tout le monde
j'ai presque lu toutes les pages du sujet. En effet je suis en train de développer un framework qui ferai une génération automatique de formulaires et qui repose pour le moment que sur une base de mySQL.
J'ai commencé par faire un système d'extraction XML et je pensé utiliser leun fichier XSL et un moteur XSLT.
Je me suis appercu qu'il existé un package PEAR QuickForm qui est bien fait d'ailleur!! Et qui gère automatiquement pas mal de truc notamment les tests.
Le problème c'est que si j'utilise quickform je ne peut plus utiliser un système de template avec XSLT. Donc comment personaliser la mise en forme des formulaires avec quickform. Et même s'il existait des méthodes permettant de le faire avec quickform, cela mélangerai complétement le code php et l'affichage.
En faite je voudrait pouvoir faire un truc qui génère automatiquement des formulaires comme quickform mais en personalisant soit même l'affichage et en séparant aux maximum le php du html.
Je me penche donc sur le système de templates.Le problème avec le système de templates, c'est:
- d'une part il ne faut pas qu'il soit trop compliqué pour le designer (et puis sinon autant le faire en PHP directement)
- en plus il existe déjà pas mal de système de template à disposition, en plus chacun apparemment aime faire sois même son système. Avec XML, XSL au moins on a un language standard, normalisé, certe assez complexe mais je pense que l'on doir pouvoir isolé le HTML du XSL... enfin un maximum. Voir notamment le lien déjà posté http://xmlfr.org/documentations/articles/001214-0001 (il faut s'accroché c'est pas si simple à comprendre mais interressant).

Donc doof tu nous parle d'un autre système de template.Il est vrai que celui à l'air tès interessant car la syntaxe s'intègre dans les balises HTML. Au moins le designer peut voir directement dans un navigateur un apercut sans passer par la moulinette du moteur de template (certe sans les boucles). Tandis que avec les autre systèmes le code html est disons "plus polué" par la syntaxe des templates (dite moi si je me trompe?).

Donc apparemment il peut s'integer à quickform!! Merveilleux! Si tu pouvais nous montrer un exmple tout simple...

Envoyé par doof

Bref, tres simple, tres puissant et tres rapide de plus c'est pear et donc il s'integre tres bien avec les autres packages comme quickform, pager.... Il est recent et gagne vraiment à être connut

Envoyé par doof

Il a cependant un énorme avantage qui ne m'était pas apparut tout de suite et qui fait que j'aurais tendance à l'appeler "l'avenir de smarty" : il dispose d'un vrai parser html/xml !

C'est grace à ce parser que l'on peut écrire la logique dans les balises grace a son espace de nomage (avoue que c'est tres élégant), et qui fait que chaque balise peut etre considérée comme bloque identifiable par son id. On peut jouer sur les attibuts, propriétés et valeurs directement, ce qui permet de gerer les forms de facon tres simple ou encore des élements XUL => C'est peut-etre bien dans ce type d'interface qu'est l'avenir justement (Microsoft prévoit un équivalent de XUL dans sa prochaine version d'IE).

Les "languages" balisés sont par essence déjà structurés, pourquoi n'avoir jammais utilisé directement leur structure ?
Alan Knowles a -a mon avis- mit le doigt sur ce que devrait être une solution de template : syntaxe simple, utilisation directe de la structure html/xml et dialogue direct avec les élements "interactifs".

En plus tu dit qu'il dispose d'un système XML!!! Comment ca marche??
Et puis qu'est que XUL? Ca sert à quoi??
MERCI d'avance pour vos réponses!

Rq: dommage que la doc de Flexy soit en anglais!

[doof]

Donc doof tu nous parle d'un autre système de template.Il est vrai que celui à l'air tès interessant car la syntaxe s'intègre dans les balises HTML. Au moins le designer peut voir directement dans un navigateur un apercut sans passer par la moulinette du moteur de template (certe sans les boucles). Tandis que avec les autre systèmes le code html est disons "plus polué" par la syntaxe des templates (dite moi si je me trompe?).

Non non, pas d'erreur, on ne defigure pas ses templates avec flexy. Il permet néamoins de mettre la logique en dehors dans des cas extremes (voir meme dans des balises propriétaires un peu comme modeliXe), ce que je n'avais pas précisé. Mais en se forcant a "penser flexy" on peut quasiment tout caser dans les balises d'origine.

Donc apparemment il peut s'integer à quickform!! Merveilleux! Si tu pouvais nous montrer un exmple tout simple...

Hmmm, apres tests, je n'en suis plus vraiment convaincu ... J'ai essayé la maniere simple qui consiste a mettre dans le template une variable qui correspond au form :

Code :

1
2
3
<div name="mondiv">
{monform:h}
</div>

Puis coté php, le creer de cette facon :

Code :

1
2
3
4
5
$form = new HTML_QuickForm('Form');
...
...
$form->addElement('submit', null, 'Envoyer');
$this->monform = $form->toHtml();

Mais bon, évidement de cette facon, on ne peut pas le travailler en wysiwyg, ce qui pert un peu de son interet. Sinon il y a bien HTML_QuickForm_Renderer_ObjectFlexy mais pour le moment j'ai pas vraiment réussit à l'utiliser correctement par manque de doc :/

En fait la principale raison pour laquelle je n'ai pas persisté avec Quickform c'est que dans flexy Il y à la classe HTML_Template_Flexy_Element qui permet déjà d'acceder directement aux elements forms du template : (exemple pour un champ input appelé 'login')

Code :

1
2
$this->elements['login'] = new HTML_Template_Flexy_Element;
$this->elements['login']->setValue('Moi');

Donc on y accede aussi simplement qu'avec quickform sauf que là, il est en 'dur' dans le template. Et pour remplir plusieurs valeurs à la fois, la classe HTML_Template_Flexy_Factory est là pour s'en charger, un simple :

Code :

$this->elements = HTML_Template_Flexy_Factory::fromArray($_POST, $this->elements);

Merge le contenu de $_POST dans le formulaire du template par exemple.

Donc toutes ces joyeuseries font que quickform me parait du coup inutile (c'est d'ailleur là que flexy commence à montrer sa puissance )

En plus tu dit qu'il dispose d'un système XML!!! Comment ca marche??

Il ne dispose pas d'un "systeme XML" mais peut ecrire dedans comme on accederait au DOM grace à son parser et ses méthodes issues de la classe "elements". il dispose des memes méthodes utilisées pour le form, setValue(), setAttributes(), removeAttributes()... sur chaque balise, ce qui est tres pratique.

Et puis qu'est que XUL? Ca sert à quoi??

C'est le language balisé de Mozilla pour decrire une interface graphique riche, reposant donc sur xml. Si tu dispose de mozilla/firefox, tu peux tester ici : http://xulplanet.com/tutorials/xultu...em/allelem.xul
Ca permet donc de faire des interfaces bien plus riches qu'en html. Ca ne marche que pour moz-firefox mais microsoft travaille sur un equivalent : XAML.
Flexy, avec son acces direct aux balises est déjà pret pour ce type d'interfaces.

Rq: dommage que la doc de Flexy soit en anglais!

Oui, et de plus assez légère (J'avance doucement en testant tout du coup). Mais quand je vois sur le nombre impressionant de projets sur lesquels Alan Knowles travaille, je comprends qu'il n'ai pas trop de temps à y consacrer... Mais ca serait bien utile !

PS : pour ton "framework" ca me parait la base ideale, sinon, Alan Knowles nous prepare déjà un framework (au sens plus large) : HTML_FlexyFramework

[chtiboss]

au faite HTML_FlexyFramework est fait en php4 dommage!
et Flexy est fait en php4 aussi on dirait? dommage aussi!
et
XUL à l'ai vraiement interessant mais en quoi Flexy peut faire du XUL??

mais HTML_FlexyFramework et Flexy ne sont'ils pas optimisé pour le php5?
J'ai vu un framework sur le net qui utilise beaucoup les classe PEAR dont Flexy
http://seagull.phpkitchen.com/
Ca à l'air pas mal mais la doc est en anglais encore!

[naholyr]

Dommage ? Absolument pas, il convient pour encore un bon moment de développer la plupart des librairies en version 4 si l'on veut qu'elles soient réellement utilisées. De nombreuses sociétés considèrent encore php5 comme non stable, ou en tous cas pas assez testé.

[doof]

XUL à l'ai vraiement interessant mais en quoi Flexy peut faire du XUL??

Il travaille de facon naturelle avec une interface XUL grace à son acces direct aux attributs et valeurs d'une balise :

Code :

1
2
3
$elements['menulist1']->attributes['disabled'] = '1';
$elements['column1']->attributes['sortdirection'] = 'descendant';
$elements['tabpanel1']->attributes['label'] = 'graphs';

De cette maniere, nul besoin de préparer des variables a remplacer dans les tags comme il faudrait le faire avec tout autre systeme de template
Il manque pour le moment la capacité a rajouter une balise (genre un menuitem comme il le fait déjà pour les options de select d'un formulaire) mais je sais qu'il y travail dessus en ce moment.

Seagul à l'air pas mal et je constate que la moitié des classes pear qu'il utilise sont l'oeuvre d'Alan Knowles

[Black-Ghost]

salut,
je suis juste de passage, j'ai pas tout lu, mais personellement j'utilise smarty, qui fait partie de PEAR, il gère très bien les templates et ce que je trouve assez interessant c'est qu'il inclue un module pour gérer le cache.

[naholyr]

Envoyé par Black-Ghost

et ce que je trouve assez interessant c'est qu'il inclue un module pour gérer le cache.

Obligé, sinon les performances s'écroulent. Le cache intégré de smarty c'est pour lui permettre de rivaliser (avec cache) avec les autres moteurs (sans cache) en terme de performances... Mais c'est une solution artificielle qui cache un problème de fond. Dommage

[10-nice]

J'utilise Smarty aussi j'en connais pas d'autre mais celui là me convient tres bien et je m'amuse ebaucoup a l'utiliser

[kerzut]

ds le dernier "login" une interview de Lerdorf conteste l'utilité des template:

• couche supplémentaire d'où baisse des performances

• argument d'empècher les graphistes de casser le code php non valable

[pascaltje]

Envoyé par kerzut

ds le dernier "login" une interview de Lerdorf conteste l'utilité des template:

• couche supplémentaire d'où baisse des performances

• argument d'empècher les graphistes de casser le code php non valable

La milli-seconde perdue à l'affichage de la page est compensée par les heures gagnées chez les codeurs (PHP et graphistes) grâce à la séparation de la présentation et de la logique du contenu.

Pour le code PHP non valable, peux tu développer?
Le graphiste peut aussi dire au développeur: "y'a un problème"

A+

Pascal

[Kioob]

Perso je n'ai aucune perte de performances (j'ai même un lèger gain, étant donné que certaines variables et/ou conditions sont compilées "en dur")...

Mais je suis d'accord sur le fait qu'on a pas besoin de templates pour séparer la présentation de la "logique de contenu".

[kerzut]

>> pascaltje

l'utilisation de template est svt justifiée en disant que cela permet de séparer le travail du graphiste de celui du développeur et dc d'empècher le vilain graphiste de casser le code du développeur. Et Lerdorf contrait cet argument en affirmant que si une entreprise n'est pas capable de faire confiance à son graphiste pr faire son travail ss casser le code, c'est que soit le graphiste est mauvais soit qu'il y a un pb de confinace au sein de l'entreprise.

[kerzut]

"un pb de confiance au sein de l'entreprise."[/b]

[loufoque]

le mieux est d'utiliser quelquechose dans le genre de Savant.