On vient de sortir une nouvelle version preliminaire de FreeMarker
2.3. Cette version, 2.3pre13, introduit une nouvelle instruction,
<#fallback>, qui est plus ou moins semblable à <xsl:apply-imports/>
dans XSLT. En général, FM 2.3 s'approche maintenant à son état final.
FreeMarker, c'est une librairie pour faire des templates
(pages-modèle) écrite en
Java. Il s'agit d'un outil assez bien connu pour générer du texte à
partir d'une page modèle réutilisable et un modèle de données basé sur
des objets Java. Originalement, ce fut conçu pour les servlets, afin
de maintenir une bonne séparation entre les détails sales de
présentation de données en HTML et la logique de l'application
sous-jacente. Divers frameworks web se servent de FreeMarker comme
composante vue, tels que JPublish, Niggle, Open for Business, et
Tammi. D'ailleurs, FreeMarker peut s'utiliser parfaitement comme
couche de présentation dans les frameworks web "modèle 2", dont Struts
est l'exemple mieux connu.
FreeMarker n'arrête pas de s'améliorer. FreeMarker 2.2 a introduit le
support pour les taglibs JSP. Un usager a dit meme qu'il était étonné
que c'était plus simple d'utiliser des taglibs JSP à partir d'un
template FreeMarker que depuis une JSP!
Avec FreeMarker 2.3, les nouveaux directifs <#visit..> et <#recurse>
peuvent bien faire que ce soit plus facile d'effectuer des
transformations recursives des documents XML (genre XSLT) en utilisant
FreeMarker que le propre XSLT!
D'ailleurs FM 2.3 additionne certaines autres nouvelles prestations.
On peut maintenant utiliser des interpolations de variables dans les
chaines litérales. Et on peut définir des fonctions dans des templates
avec des valeurs de retour.
Bref, pour ceux entre vous qui soyez ouverts à vous rendre la vie plus
facile en trouvant des alternatives plus agreables à des trucs mieux
connus (et avec plus de "hype" derrière) tels que JSP ou XSLT,
FreeMarker mérite vraiment un regard sérieux.
Pour plus de renseignements, vous pouvez visiter
http://freemarker.org/ (ou
http://freemarker.sourceforge.net/) ou la page du project FreeMarker
à
http://sf.net/projects/freemarker .
Salutations Amicales,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Franck Guillaud
Jonathan Revusky wrote:
Avec FreeMarker 2.3, les nouveaux directifs <#visit..> et <#recurse> peuvent bien faire que ce soit plus facile d'effectuer des transformations recursives des documents XML (genre XSLT) en utilisant FreeMarker que le propre XSLT!
FreeMarker est-il capable de s'appliquer sur un source ... Freemarker ?
Franck.
Jonathan Revusky wrote:
Avec FreeMarker 2.3, les nouveaux directifs <#visit..> et <#recurse>
peuvent bien faire que ce soit plus facile d'effectuer des
transformations recursives des documents XML (genre XSLT) en utilisant
FreeMarker que le propre XSLT!
FreeMarker est-il capable de s'appliquer sur un source ... Freemarker ?
Avec FreeMarker 2.3, les nouveaux directifs <#visit..> et <#recurse> peuvent bien faire que ce soit plus facile d'effectuer des transformations recursives des documents XML (genre XSLT) en utilisant FreeMarker que le propre XSLT!
FreeMarker est-il capable de s'appliquer sur un source ... Freemarker ?
Franck.
jrevusky
"Franck Guillaud" wrote in message news:<bj9b96$2p9g$...
Jonathan Revusky wrote:
Avec FreeMarker 2.3, les nouveaux directifs <#visit..> et <#recurse> peuvent bien faire que ce soit plus facile d'effectuer des transformations recursives des documents XML (genre XSLT) en utilisant FreeMarker que le propre XSLT!
FreeMarker est-il capable de s'appliquer sur un source ... Freemarker ?
Ah bon. Une question intéressante. :-)
La réponse, c'est que, actuellement, non. Pas directement. Ça serait possible si les nodes de l'arbre construit par le parseur de FreeMarker implementait l'interface freemarker.template.TemplateNodeModel. Donc, on pourrait "visiter" l'arbre d'une source FreeMarker tout-à-fait de la même façon qu'on peut "visiter" recursivement les nodes s'un arbre XML.
Cela est assez intéressant et il est bien possible qu'on fasse un refactoring semblable dans une version dans l'avenir.
En fait, je crois que Stephan Mueller a écrit des adapteurs qui emballent ces objets-là, et qui, à son tour, implémente TemplateNodeModel, et donc, il a pu appliquer FreeMarker à une source FreeMarker.
Bon, pourquoi tu poses la question? Je veux dire, c'est quand-même un scénario d'usager un petit peu poussé, n'est-ce pas? (Bon, on a le scénario d'un XSLT qui transforme à son tour un autre XSLT, mais est-ce qu'on fait ça souvent? Stephan s'y intéresse, par exemple, parce qu'il écrit des outils pour travailler avec des sources FM, notamment, le plug-in pour Eclipse.)
Salutations Amicales,
Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/
Franck.
"Franck Guillaud" <f@nospam.org> wrote in message news:<bj9b96$2p9g$1@news6.isdnet.net>...
Jonathan Revusky wrote:
Avec FreeMarker 2.3, les nouveaux directifs <#visit..> et <#recurse>
peuvent bien faire que ce soit plus facile d'effectuer des
transformations recursives des documents XML (genre XSLT) en utilisant
FreeMarker que le propre XSLT!
FreeMarker est-il capable de s'appliquer sur un source ... Freemarker ?
Ah bon. Une question intéressante. :-)
La réponse, c'est que, actuellement, non. Pas directement. Ça serait
possible si les nodes de l'arbre construit par le parseur de
FreeMarker implementait l'interface
freemarker.template.TemplateNodeModel. Donc, on pourrait "visiter"
l'arbre d'une source FreeMarker tout-à-fait de la même façon qu'on
peut "visiter" recursivement les nodes s'un arbre XML.
Cela est assez intéressant et il est bien possible qu'on fasse un
refactoring semblable dans une version dans l'avenir.
En fait, je crois que Stephan Mueller a écrit des adapteurs qui
emballent ces objets-là, et qui, à son tour, implémente
TemplateNodeModel, et donc, il a pu appliquer FreeMarker à une source
FreeMarker.
Bon, pourquoi tu poses la question? Je veux dire, c'est quand-même un
scénario d'usager un petit peu poussé, n'est-ce pas? (Bon, on a le
scénario d'un XSLT qui transforme à son tour un autre XSLT, mais
est-ce qu'on fait ça souvent? Stephan s'y intéresse, par exemple,
parce qu'il écrit des outils pour travailler avec des sources FM,
notamment, le plug-in pour Eclipse.)
Salutations Amicales,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
"Franck Guillaud" wrote in message news:<bj9b96$2p9g$...
Jonathan Revusky wrote:
Avec FreeMarker 2.3, les nouveaux directifs <#visit..> et <#recurse> peuvent bien faire que ce soit plus facile d'effectuer des transformations recursives des documents XML (genre XSLT) en utilisant FreeMarker que le propre XSLT!
FreeMarker est-il capable de s'appliquer sur un source ... Freemarker ?
Ah bon. Une question intéressante. :-)
La réponse, c'est que, actuellement, non. Pas directement. Ça serait possible si les nodes de l'arbre construit par le parseur de FreeMarker implementait l'interface freemarker.template.TemplateNodeModel. Donc, on pourrait "visiter" l'arbre d'une source FreeMarker tout-à-fait de la même façon qu'on peut "visiter" recursivement les nodes s'un arbre XML.
Cela est assez intéressant et il est bien possible qu'on fasse un refactoring semblable dans une version dans l'avenir.
En fait, je crois que Stephan Mueller a écrit des adapteurs qui emballent ces objets-là, et qui, à son tour, implémente TemplateNodeModel, et donc, il a pu appliquer FreeMarker à une source FreeMarker.
Bon, pourquoi tu poses la question? Je veux dire, c'est quand-même un scénario d'usager un petit peu poussé, n'est-ce pas? (Bon, on a le scénario d'un XSLT qui transforme à son tour un autre XSLT, mais est-ce qu'on fait ça souvent? Stephan s'y intéresse, par exemple, parce qu'il écrit des outils pour travailler avec des sources FM, notamment, le plug-in pour Eclipse.)
Salutations Amicales,
Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/
Franck.
Franck Guillaud
Jonathan Revusky wrote:
Bon, pourquoi tu poses la question? Je veux dire, c'est quand-même un scénario d'usager un petit peu poussé, n'est-ce pas? (Bon, on a le scénario d'un XSLT qui transforme à son tour un autre XSLT, mais est-ce qu'on fait ça souvent? Stephan s'y intéresse, par exemple, parce qu'il écrit des outils pour travailler avec des sources FM, notamment, le plug-in pour Eclipse.)
Je pose la question parce que tu as fait la comparaison avec XSLT :-)
Le grand avantage des standards W3C, c'est que c'est tout XML.
Et si effectivement c'est une utilisation peu courante que de transformer du XSLT, ça m'arrive quand même de temps en temps.
Franck.
Salutations Amicales,
Jonathan Revusky
Franck.
Jonathan Revusky wrote:
Bon, pourquoi tu poses la question? Je veux dire, c'est quand-même un
scénario d'usager un petit peu poussé, n'est-ce pas? (Bon, on a le
scénario d'un XSLT qui transforme à son tour un autre XSLT, mais
est-ce qu'on fait ça souvent? Stephan s'y intéresse, par exemple,
parce qu'il écrit des outils pour travailler avec des sources FM,
notamment, le plug-in pour Eclipse.)
Je pose la question parce que tu as fait la comparaison avec XSLT :-)
Le grand avantage des standards W3C, c'est que c'est tout XML.
Et si effectivement c'est une utilisation peu courante que de transformer
du XSLT,
ça m'arrive quand même de temps en temps.
Bon, pourquoi tu poses la question? Je veux dire, c'est quand-même un scénario d'usager un petit peu poussé, n'est-ce pas? (Bon, on a le scénario d'un XSLT qui transforme à son tour un autre XSLT, mais est-ce qu'on fait ça souvent? Stephan s'y intéresse, par exemple, parce qu'il écrit des outils pour travailler avec des sources FM, notamment, le plug-in pour Eclipse.)
Je pose la question parce que tu as fait la comparaison avec XSLT :-)
Le grand avantage des standards W3C, c'est que c'est tout XML.
Et si effectivement c'est une utilisation peu courante que de transformer du XSLT, ça m'arrive quand même de temps en temps.
