Mais jTpl il peut fonctionner en dehors de jelix ?
2.
Le mercredi, février 14 2007, 12:28 par laurentj
oui, y a une version standalone en téléchargement. faut que je fasse une doc d'ailleurs sur cette version :-)
3.
Le mercredi, février 14 2007, 14:09 par Nikoals
Attention quand même, sur IRC il y a beaucoup d'ironie ;)
4.
Le mercredi, février 14 2007, 14:17 par laurentj
@Nikoals : non non, ils n'ironisaient pas, pas quand on sait où ils travaillent ;-)
5.
Le mercredi, février 14 2007, 16:46 par Raphael
Ca m'a l'air bien pense.
Helas c'est pas du 100% xml.
C'est redibitoire pour moi :
Pour pouvoir l'editer avec des editeurs XML, le filer a des web-designer, l'importer dans des truc wysiwyg, le processer avec du javascript, le DOM, du python facilement etc.
Dommage.
6.
Le mercredi, février 14 2007, 17:22 par laurentj
@raphael : j'ai déjà fait un moteur de template en XML. C'est en fait à l'usage beaucoup trop chiant car tu as un langage trop rigide. Pour faire des structures de contrôles c'est merdique. Ou encore, avoir une balise xml qui indiquerait que l'attribut de telle balise que tu veux générer, elle contiendra telle valeur. C'est compliqué à souhait (pour le moteur), c'est ultra verbeux pour celui qui fait le template (y a qu'à voir le moteur modelix, c'est beurk je trouve)etc..
De plus, cela impose que le contenu d'un template soit valide, OR le but d'un template, c'est quand même de générer un document valide, à partir de morceau qui ne soit pas forcément valides à la base. Un exemple :
Le document n'est pas valide... À moins de répeter dans chacun des cas des tonnes d'informations. Ou alors avoir d'autres types de balises pour pouvoir modifier le type de la balise que l'on veut générer, mais alors on fini par avoir un vocabulaire vaste et verbeux.
De plus, je trouve que finalement on s'y perd dans le template : le mélange entre les balises du langage de template et les balises du futur document entraine une confusion (surtout dans les templates complexes).
Enfin, dans le cadre d'une appli web, tu n'a pas que des fichiers XML à générer. Cela peut être du texte, du wiki, du json ou n'importe quoi d'autres. Et alors il n'est pas interressant d'avoir un langage de template en XML.
À cela il faut ajouter l'hyper lourdeur des traitements XML (par rapport à un autre système de template comme jtpl).
C'est pourquoi je n'ai pas choisi un langage XML. Et les templates de jelix ne sont pas déstinées à être parsées par autre chose que du php, donc, j'ai choisi au plus simple et au plus efficace...
XMLisé tout n'est pas toujours un avantage.
7.
Le mercredi, février 14 2007, 17:24 par laurentj
Ce qui est sympa pour les templates c'est de pouvoir faire des overlays, comme en XUL.
En plus ça permet une bonne intégration des modules d'extension etc.
@anon : oui, mais pas sécurisé (par ex pour des templates provenant d'un user dans un CMS), chiant à écrire (tout ces <?php echo ...), trop tentant pour mélanger code metier/code génération de contenu, et enfin, les balises php sont trop pertubatrices dans un éditeur wysiwyg.
Mais le langage de template utilisé dans jtpl n'empêche pas de transformer les templates sous forme PHP et de mettre ça en cache ;-) ce que fait jtpl en interne ...
D'après ce que j'ai pu voir ... Je crois pouvoir dire que jtpl n'existerait pas sans smarty ;-) Ou pas dans cette forme du moins. Car ça s'inspire énormément de smarty à pas mal de niveau ... Donc, merci de respecter l'original ;-), qui est bien bien antérieur !
ben regardes mieux. la similitude avec smarty est minime tout de même : des accolades pour encadrer les instructions, la syntaxe des modificateurs, l'idée des plugins. Et c'est tout. Il est vrai que je me suis un peu inspirer de smarty au début, dans l'esprit, mais de là à dire que jtpl n'existerait pas sans smarty, c'est un peu fort... Par exemple, la syntaxe des paramètres, c'est une syntaxe horrible ressemblant à rien dans smarty, mais c'est du PHP dans jTpl. Et regardes le code source de jTpl : 4 fois moins important, plus performant et pas une seule ligne de code en commun.
J'ai été un vrai fan de smarty jadis, et je l'ai également refait dans divers languages (asp, csharp.net, python) (mais moins poussé que jtpl). Je pense bien connaître la bête ...
En regardant de loin jtpl, on reconnait "smarty" : la creation de l'objet, les assign, le fetch/display ... et le coté templates : les plugins modifiers/block/functions (ça, c'est clairement smarty qui a initié ce concept) ... après on retrouve les syntaxes classiques (if/else/foreach...) à la smarty.
Par rapport à d'autres moteurs de templates php, comme modelix et consorts ... ça ressemble plus à smarty ;-) (et tant mieux !)
Le code est peut être 4x plus lite/performant (avec l'héritage en sus : bravo !) ... mais tu n'implémentes pas tout smarty non plus (les zones dynamiques, les filters, le debuguer ... et la foultitude de plugins livrés avec)
Bon maintenant je pinaille ... mais j'étais un grand grand fan de smarty ! Et ton boulot est néanmoins excellent ! bravo ...
mais tu n'implémentes pas tout smarty non plus (les zones dynamiques, les filters, le debuguer ... et la foultitude de plugins livrés avec)
vrai, mais, de par mon experience, ça a toujours été des gadgets pour moi, ou alors des fonctionnalités redondantes avec ce que propose les frameworks. Par exemple, dans Copix, smarty est loin d'être utilisé à son plein potentiel, tout simplement parce que nombre de fonctionnalités sont totalement inutiles ou font double emploi dans ce cadre là. C'est d'ailleurs une des grandes raisons pourquoi j'ai viré smarty quand j'ai forké Copix (pour devenir Jelix :-) )
16.
Le mercredi, février 21 2007, 18:14 par goetsu
Commentaires
Mais jTpl il peut fonctionner en dehors de jelix ?
oui, y a une version standalone en téléchargement. faut que je fasse une doc d'ailleurs sur cette version :-)
Attention quand même, sur IRC il y a beaucoup d'ironie ;)
@Nikoals : non non, ils n'ironisaient pas, pas quand on sait où ils travaillent ;-)
Ca m'a l'air bien pense. Helas c'est pas du 100% xml. C'est redibitoire pour moi : Pour pouvoir l'editer avec des editeurs XML, le filer a des web-designer, l'importer dans des truc wysiwyg, le processer avec du javascript, le DOM, du python facilement etc.
Dommage.
@raphael : j'ai déjà fait un moteur de template en XML. C'est en fait à l'usage beaucoup trop chiant car tu as un langage trop rigide. Pour faire des structures de contrôles c'est merdique. Ou encore, avoir une balise xml qui indiquerait que l'attribut de telle balise que tu veux générer, elle contiendra telle valeur. C'est compliqué à souhait (pour le moteur), c'est ultra verbeux pour celui qui fait le template (y a qu'à voir le moteur modelix, c'est beurk je trouve)etc..
De plus, cela impose que le contenu d'un template soit valide, OR le but d'un template, c'est quand même de générer un document valide, à partir de morceau qui ne soit pas forcément valides à la base. Un exemple :
<t:if expr="foo == 'bar'"/> <ul> <t:else/> <ol> <t:endif/> <li>...</li>Le document n'est pas valide... À moins de répeter dans chacun des cas des tonnes d'informations. Ou alors avoir d'autres types de balises pour pouvoir modifier le type de la balise que l'on veut générer, mais alors on fini par avoir un vocabulaire vaste et verbeux.
De plus, je trouve que finalement on s'y perd dans le template : le mélange entre les balises du langage de template et les balises du futur document entraine une confusion (surtout dans les templates complexes).
Enfin, dans le cadre d'une appli web, tu n'a pas que des fichiers XML à générer. Cela peut être du texte, du wiki, du json ou n'importe quoi d'autres. Et alors il n'est pas interressant d'avoir un langage de template en XML.
À cela il faut ajouter l'hyper lourdeur des traitements XML (par rapport à un autre système de template comme jtpl).
C'est pourquoi je n'ai pas choisi un langage XML. Et les templates de jelix ne sont pas déstinées à être parsées par autre chose que du php, donc, j'ai choisi au plus simple et au plus efficace...
XMLisé tout n'est pas toujours un avantage.
J'oubliais, mon fameux moteur de template (pour javascript ;-) ) avec un langage XML : /blog/2004/08/18/329-jstemplatebuilder
@raphael, sinon, si tu veux un langage de template : y a XSLT :-p (mais bon, plus horrible comme langage XML, y a pas)
Stro con, PHP est déjà un super moteur de template à la base.
Ce qui est sympa pour les templates c'est de pouvoir faire des overlays, comme en XUL. En plus ça permet une bonne intégration des modules d'extension etc.
@anon : oui, mais pas sécurisé (par ex pour des templates provenant d'un user dans un CMS), chiant à écrire (tout ces <?php echo ...), trop tentant pour mélanger code metier/code génération de contenu, et enfin, les balises php sont trop pertubatrices dans un éditeur wysiwyg.
Mais le langage de template utilisé dans jtpl n'empêche pas de transformer les templates sous forme PHP et de mettre ça en cache ;-) ce que fait jtpl en interne ...
D'après ce que j'ai pu voir ... Je crois pouvoir dire que jtpl n'existerait pas sans smarty ;-) Ou pas dans cette forme du moins. Car ça s'inspire énormément de smarty à pas mal de niveau ... Donc, merci de respecter l'original ;-), qui est bien bien antérieur !
@manatlan :
ben regardes mieux. la similitude avec smarty est minime tout de même : des accolades pour encadrer les instructions, la syntaxe des modificateurs, l'idée des plugins. Et c'est tout. Il est vrai que je me suis un peu inspirer de smarty au début, dans l'esprit, mais de là à dire que jtpl n'existerait pas sans smarty, c'est un peu fort... Par exemple, la syntaxe des paramètres, c'est une syntaxe horrible ressemblant à rien dans smarty, mais c'est du PHP dans jTpl. Et regardes le code source de jTpl : 4 fois moins important, plus performant et pas une seule ligne de code en commun.
J'ai été un vrai fan de smarty jadis, et je l'ai également refait dans divers languages (asp, csharp.net, python) (mais moins poussé que jtpl). Je pense bien connaître la bête ... En regardant de loin jtpl, on reconnait "smarty" : la creation de l'objet, les assign, le fetch/display ... et le coté templates : les plugins modifiers/block/functions (ça, c'est clairement smarty qui a initié ce concept) ... après on retrouve les syntaxes classiques (if/else/foreach...) à la smarty. Par rapport à d'autres moteurs de templates php, comme modelix et consorts ... ça ressemble plus à smarty ;-) (et tant mieux !) Le code est peut être 4x plus lite/performant (avec l'héritage en sus : bravo !) ... mais tu n'implémentes pas tout smarty non plus (les zones dynamiques, les filters, le debuguer ... et la foultitude de plugins livrés avec) Bon maintenant je pinaille ... mais j'étais un grand grand fan de smarty ! Et ton boulot est néanmoins excellent ! bravo ...
vrai, mais, de par mon experience, ça a toujours été des gadgets pour moi, ou alors des fonctionnalités redondantes avec ce que propose les frameworks. Par exemple, dans Copix, smarty est loin d'être utilisé à son plein potentiel, tout simplement parce que nombre de fonctionnalités sont totalement inutiles ou font double emploi dans ce cadre là. C'est d'ailleurs une des grandes raisons pourquoi j'ai viré smarty quand j'ai forké Copix (pour devenir Jelix :-) )
j'attend la doc avec impatience alors