Discussion :

[Spack]

Salut,
en lisant ce topic j'ai téléchargé phpLib qui me parrait avoir une syntaxe plutôt clair afin de s'initier aux templates par contre lors de l'exécution j'ai cette erreur...

Undefined offset: 0 in template.inc on line 320

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$this->set_var($varname, $m[1][0]);

Savez-vous comment résoudre ce problème :
J'ai été sur le site du projet mais je n'ai pas plus d'infos

[pascaltje]

Salut,
en lisant ce topic j'ai téléchargé phpLib qui me parrait avoir une syntaxe plutôt clair afin de s'initier aux templates par contre lors de l'exécution j'ai cette erreur...

Undefined offset: 0 in template.inc on line 320

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$this->set_var($varname, $m[1][0]);

Savez-vous comment résoudre ce problème :
J'ai été sur le site du projet mais je n'ai pas plus d'infos

C'est tout simplement un indice de tableau qui n'existe pas, donc PHP le signale.

j'ai remplacé la ligne par:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
if(isset($m[1][0]))
	    $this->set_var($varname, $m[1][0]);

et ça marche nickel

A+

Pascal

[Spack]

ok merci

[cedricgirard]

La phplib a semble t'il été développé pour php3 avec un error_reporting <> E_ALL, donc pas mal de trucs font des warning si on force le niveau d'erreurs un peu plus haut.

[TheDarkLewis]

Salut,

J'ai pas lu les 10 pages du topic, mais ...


Après avoir essayé PHPLib, que je trouvais bien, j'ai essaye TemplatePower (gratuit aussi), qui est JE DIT BIEN MILLE FOIS MIEUX ...


* Il est "quasiment" comme PHPLib, mais on n'a plus besoin de déclarer les blocks !!! (il les trouves tout seul), on peut inclure des templates directement dans des templates, voire même du code php !!!



Bref, c'est pas pour faire de la pub, mais pk s'en priver ?


PS : Ya aussi si vous voulez un système de cache ...

[cedricgirard]

Salut

je suis allé faire un tour dans la doc, et je vois bien des déclarations de blocs, donc peux tu expliquer ce que tu entend par "on n'a plus besoin de déclarer les blocks"?
La seule chose que je fasse avec Xtemplate (je ne connais pas celui de phplib) c'est $tpl->parse('MONBLOC'); ce qui me semble correspondre à prepare()
Pour l'inclusion directe de template j'en ai eu besoin une fois mais ça peut servir. Par contre du PHP dans un template me semble être une erreur, les templates sont le domaine du graphiste, le code celui du développeur, on les sépare exprès, pourquoi les réinclure?

[doof]

Je me met doucement a Flexy de PEAR que je trouve excellent ! (avant j'utilisais mon propre systeme où la simplicité était la priorité... Flexy reste tout aussi simple mais tres puissant).

un exemple de boucle + condition:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<table border="1" flexy:if="membres">
    <tr flexy:foreach="membres,row">
        <td>{row[id]}</td><td>{row[nom]}</td><td>{row[prenom]}</td>
    </tr>
</table>

Comme on peut voir, la contition est directement dans la balise <table> (si $membres existe) et la boucle directement dans la balise <tr> (pour tout le tableau $membres, recuperer la clée en tant que "row")! Peut-on rever plus propre ?

Du coup, la notion de bloque devient inutile, j'ai d'ailleurs rien trouvé a ce sujet.

Cerise sur le gateau : rien à assigner, tout est objet, il suffit donc de preparer son objet représantant la structure des variables et les noms utilisés dans le template sont les memes, l'objet permetant d'eviter l'effet de bord avec les autres variables du script.

Un atribut de l'objet peut bien sur etre un objet lui meme, dans ce cas, on y accede dans le template le plus simplement du monde : {instance.valeur}.

On peut appeler aussi dans le template directement une méthode : {foobar()}, en lui passant des valeurs si ca nous chante : {foobar(value, #string#)}. En sachant qu'une méthode peut appeler un autre template, je vous laisse deviner les possibilités.

Il compile un template en script php/html au premier appel (de maniere optimisée, avec des <?php ?> partout), et ensuite fait toujours appel au script compilé, ce qui le rend tres rapide vu qu'il n'y a plus de parsing/analyse. Si l'on modifie le fichier template ou le fichier .php, il le recompile automatiquement (bien sur, c'est configurable).

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

[Kioob]

Effectivement, c'est le premier template qui me semble vraiment interessant :
1) "compilation" du template
2) pas vraiment d'assignation des variables
3) sécurisé (en modifiant le template on a pas accès pour autant à toutes les fonctions et variables. on est limité à l'objet actuel).
4) syntaxe simple

je sens que je vais adopter ou au moins m'en inspirer fortement...

[naholyr]

ça a l'air impressionnant cette petite chose

[genova]

Impressionant en effet, mais prend pas mal de fichiers

[doof]

Comme tout package pear, il y a plusieurs fichiers certes mais on les met tous dans un repertoire et on en entend plus parler ensuite. De plus le code étant bien séparé, ca permet de l'étendre facilement.

A propos des bloques, j'avais dit que j'ai rien trouvé à ce propos, je viens enfin de trouver :

support for id blocks
$flexy->compile('sometemplate.html#mytag');
will compile a file {compileDir}/sometemplate.html#mytag
which contains the tag and contents of <span id="mytag"> ... </span>

Encore une idée simple mais redoutable : tout element ayant une id est un bloque !!

[Mr.KisS]

J'utilise pour ma part Smarty qui me semble complet et très utiles les fonctions qui peuvent aider à l'affichage du texte (truncate, etc.) qui sont des alias aux fonctions PHP! Bref, j'apprécie beaucoup Smarty qui m'a fait aimer les Templates qui jusqu'à là, je n'avais jamais appréçiés :/

Je les ai pas tous étudié, tout le monde m'a conseillé ceux ci sur un autre forum donc j'ai un peu lui et j'ai adhéré!

[TheDarkLewis]

cedricgirard, pour les déclarations de blocks, je parlais dans le fichier PHP.

Dans PHPLib il fallait les déclarer avec utilisation, la y'a plus besoin avec PowerTemplate ...

[Alkmie]

Jusqu'à présent j'utilisais Smarty comme moteur de templates... la semaine dernière pour inaugurer mon blog (vi encore un ) je me suis dis que j'allais faire un article à l'éloge de Smarty...

Puis finalement, je me suis dis que comme ça faisait un moment que je ne m'étais pas renseigné sur l'actualité des moteurs de templates, je suis venu par ici et relu l'intégralité des posts...

Au final, je suis tombé sur le post de naholyr et ça m'a fait vachement réfléchir... au final j'ai pondu un petit article intitulé l'après smarty... je détaille ce que naholyr a ennoncé en présentant comment se passer de smarty une fois qu'on a compris comment il marche... on obtient une méthode de développement s'insipirant fortement des templates mais sans leur faire appel...

Du coup, j'aimerai avoir votre avis là dessus, et surtout savoir pourquoi des usines à gaz comme smarty tirent leur épingle du jeu !!

[doof]

Intéressant tout ca en effet, ca fait réfléchir

Mais je pense néanmoins que même si php lui meme est une solution de template, et de surcroit puissante, elle restera toujours plus compliquée qu'une solution de template bien concue, je reprends pour exemple le cas du foreach dans ton article 'l'apres smarty'

//SMARTY
{section name=value loop=$listValues}
{$listValues[value].name}
{/section}
ou
{foreach item=value from=$listValues}
{$value.name}
{/foreach}
//PHP
[?php foreach($listValue as $value): ?]
[?=$value['name']?]
[?php endforeach; ?]

On voit donc qu'en effet, il parait inutile de réécrire un langage alors que c'est aussi simple directement en php.
Mais là ou il y a une faiblesse, c'est que dans cet exemple, il n'y a aucune vérification, pour reprendre mon exemple sur flexy :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<table border="1" flexy:if="membres">
    <tr flexy:foreach="membres,row">
        <td>{row[id]}</td><td>{row[nom]}</td><td>{row[prenom]}</td>
    </tr>
</table>

devient une fois "compilé" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<?php if ($t->membres)  {?><table border="1">
    <?php if ($this->options['strict'] || (is_array($t->membres)  || is_object($t->membres))) foreach($t->membres as $row) {?><tr>
        <td><?php echo htmlspecialchars($row['id']);?></td><td><?php echo htmlspecialchars($row['nom']);?></td><td><?php echo htmlspecialchars($row['prenom']);?></td>
    </tr><?php }?>
</table><?php }?>

Ont voit donc bien que le moteur de template ne fait pas "que traduire" la logique de présentation mais rajoute implicitement beaucoup d'autres choses comme la verification de variables et mise en forme qui seraient lourds à traiter en php pour le designer.

Je reste donc persuadé que la solution template *si elle est bien concue* remplace tres avantageusement le php dans du html.

Maintenant, pour en revenir au cas de Smarty, mon avis est que 80% de ses fonctionalités sont totalement inutiles. En effet, je suis bien conscient que la présentation à besoin d'une logique mais cette logique n'a finalement pas besoin de grand chose : conditions et bouclage. Pour traiter des cas complexes de conditions, comme tu le fait remarquer à juste titre, définir une fonction sur mesure appelée dans cette condition peut résoudre tous les cas de figure. Smarty permet ca mais pourquoi en faire plus ? Poudre aux yeux ?

Flexy lui se contente de ces 3 possibilités ce qui lui permet d'avoir une "runtime" bien plus legere en ayant les memes possibilités. 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".

[naholyr]

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

N'est-ce pas également le cas de ModeliXe ?

[doof]

Sans bien connaitre modeliXe, il me semble qu'il se "contente" de rajouter ses propres balises et ses propres atributs dynamiques, du genre mXattribut="bgcolor:couleur".

Un champ de form donnerait par exemple : (tiré de l'exemple)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<mx:formField id="motdepasse" size="30" maxlength="50"/>

Il n'utilise donc pas directement les vrais balises mais bel et bien les siennes. (impossible de travailler ca en wysywyg).

Maintenant, je peux me tromper bien sur

[jeca]

Bonjour,

impossible de travailler ca en wysywyg

Il existe un addon pour dreamweaver.

http://modelixe.phpedit.com/telechar...lang=fr&idlog=

[doof]

L'idéal est justement de pouvoir utiliser un élement nativement sans le défigurer, et sans avoir besoin de plug-in pour l'éditer avec son éditeur préféré.
Faut-il aussi un plug-in pour gerer un menulist en XUL ?

[naholyr]

Quand on voit un travail comme Flexy, il faut bien reconnaître qu'on se sent tout penaud, et qu'on se dit que c'est la voie à suivre, qu'il n'y a aucun doute là-dessus. On se demanderait même comment on a pu se fourvoyer dans d'autres pistes sans penser à celle-là.

En tous cas c'est ce que je me dis. Et je suis encore plus surpris de voir que modeliXe n'a pas suivi cette voie alors qu'ils en étaient si proches