You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@yahoo.de> on 2004/11/01 17:30:19 UTC
Templating Engine - Next steps?
After a lot of mails talking about expression languages and templating enginges
I try to summarize the current state of our discussion. I see following
requirements so far (in brackets you find the name of the person that brought up
the requirement):
- control structures like for/each, if, choose (RP)
- call methods in a _simple/natural_ way on passed objects (RP)
- stream objects (DOM, XMLizable, ...?) (RP)
- define macros/taglibs (see cForm macros) (RP)
- works as a Transformer (SAX pipeline) (GP)
- Ability to directly produce SAX events, for efficency reasons. (SW)
- one default expression language (CZ)
it thing most people prefer the "dotted" JEXL syntax
- support for additional expression languages (SW)
- use the TemplateObjectModelHelper as Cocoon wide object model (CZ)
and not to forget
- cacheability (RP)
(BTW, has caching been implemented to everybodies satisfaction or
are there open issues or possible improvements? Leszek?)
and one issue that bugs me for a long time ...
- add support for dynamic attributes - similar to xsl:attribute (RP)
- o -
So, how do we continue to meet all these requirements?
A.) Rewrite/refactor JXTemplate
- break it up in smaller, easier understandable/maintainable pieces
- deprecate #{} syntax and make expression languages plugable as
Sylvain suggested
- investigate the performance problems (I guess there are only
problems if macros are used)
- add the missing things from above
B.) use Garbage
C.) talk with Carsten about Tempo
D.) completly new templating engine
- o -
In my opinion we should write JXTemplate 2.0 which would be from the user's POV
as similar as possible to 1.0.
Technically this could be a complete rewrite (use garbage, tempo or really from
scratch) or at least a major refactoring.
Calling it JXTemplate is better for marketing reasons because it shows more
stability than telling our user base that they should use something completly
different in the future. Calling it differently gives another impression than
incrementing version numbers.
WDOT ...
* are there any missing requirments?
* or is it too much (FS)?
* which alternative do you prefer?
Don't forget, this is no vote ;-)
--
Reinhard
RE: Templating Engine - Next steps?
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> E.) Use Jelly: http://jakarta.apache.org/commons/jelly/
>
> AFAIK Jelly allready solve most of the requirements above.
> More specifically it uses JEXL or Jaxen as expression
> language, and you can use expressions both in attributes and
> in text with the syntax "${expr}". The expression engine is
> pluggable, so one can implement an Expression interface and
> use another expression language, JXPath e.g.
>
> In Jelly there are simple mechanisms for writing own tag
> libs. And a large number of tag libs are already implemented.
> It read and writes SAX. It also have mechanisms for compiling
> the template so that id doesn't need to be parsed again, if
> used several times.
>
Jelly has imho a very awkward design that has several problems
when used in Cocoon - I looked at it some months ago and had some
discussions with Jelly developers. I don't remember any details,
but the result was that it isn't suitable to be used inside
Cocoon. Ok, this is a very general statement without any proof,
but that's all I can currently say. Other projects, like Maven,
aren't happy with Jelly either.
But you're right that it is a potential candidate to consider.
Now, whoever does this job is free to decide :)
Carsten
Re: Templating Engine - Next steps?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> After a lot of mails talking about expression languages and templating
> enginges I try to summarize the current state of our discussion. I
> see following requirements so far (in brackets you find the name of
> the person that brought up the requirement):
>
> - control structures like for/each, if, choose (RP)
> - call methods in a _simple/natural_ way on passed objects (RP)
> - stream objects (DOM, XMLizable, ...?) (RP)
> - define macros/taglibs (see cForm macros) (RP)
> - works as a Transformer (SAX pipeline) (GP)
> - Ability to directly produce SAX events, for efficency reasons. (SW)
> - one default expression language (CZ)
> it thing most people prefer the "dotted" JEXL syntax
I prefer Xpath and would prefer to make the choice of default expression
language configurable.
> - support for additional expression languages (SW)
> - use the TemplateObjectModelHelper as Cocoon wide object model (CZ)
>
> and not to forget
>
> - cacheability (RP)
> (BTW, has caching been implemented to everybodies satisfaction or
> are there open issues or possible improvements? Leszek?)
>
> and one issue that bugs me for a long time ...
>
> - add support for dynamic attributes - similar to xsl:attribute (RP)
>
> - o -
>
> So, how do we continue to meet all these requirements?
>
> A.) Rewrite/refactor JXTemplate
> - break it up in smaller, easier understandable/maintainable pieces
> - deprecate #{} syntax and make expression languages plugable as
> Sylvain suggested
> - investigate the performance problems (I guess there are only
> problems if macros are used)
> - add the missing things from above
>
> B.) use Garbage
>
> C.) talk with Carsten about Tempo
>
> D.) completly new templating engine
E.) Use Jelly: http://jakarta.apache.org/commons/jelly/
AFAIK Jelly allready solve most of the requirements above. More
specifically it uses JEXL or Jaxen as expression language, and you can
use expressions both in attributes and in text with the syntax
"${expr}". The expression engine is pluggable, so one can implement an
Expression interface and use another expression language, JXPath e.g.
In Jelly there are simple mechanisms for writing own tag libs. And a
large number of tag libs are already implemented. It read and writes
SAX. It also have mechanisms for compiling the template so that id
doesn't need to be parsed again, if used several times.
> In my opinion we should write JXTemplate 2.0 which would be from the
> user's POV as similar as possible to 1.0.
> Technically this could be a complete rewrite (use garbage, tempo or
> really from scratch) or at least a major refactoring.
IIUC, JXTemplate 1.0, except for the "#{expr}" sytax can be implemented
in Jelly. So we would keep it (almost) back compatible, and would get a
lot of new template libraries and good mechanisms for writing our own,
for free.
> Calling it JXTemplate is better for marketing reasons because it shows
> more stability than telling our user base that they should use
> something completly different in the future. Calling it differently
> gives another impression than incrementing version numbers.
>
>
> WDOT ...
> * are there any missing requirments?
Not IMO, but I would like to emphazise the need for writing tag libs. We
have a lot of transformers, e.g. the SQLTransformer, that basically
implements a tag lib. IMO all these custom transformers that are written
more or less directly in terms of SAX, are quite hard to write,
understand and support. I think it would be much better to write such
tag libs in something that is a little bit more high level e.g. as Jelly
tag libs.
> * or is it too much (FS)?
In one way I agree with the ideas behind StringTemplate, among other
things, that a template language should be side effect free. But on the
other hand we need both an expression language and the ability to define
own tag libraries, and that makes it nearly impossible to enforce
freeness from side effects.
> * which alternative do you prefer?
JXTemplate 2.0 implemented in Jelly.
>
> Don't forget, this is no vote ;-)
>
+1 ;)
/Daniel
Re: XML Templating Engine - Next steps?
Posted by Reinhard Poetz <re...@yahoo.de>.
Bertrand Delacretaz wrote:
> Le 1 nov. 04, à 17:30, Reinhard Poetz a écrit :
>
>> After a lot of mails talking about expression languages and templating
>> enginges I try to summarize the current state of our discussion. I
>> see following requirements so far (in brackets you find the name of
>> the person that brought up the requirement):..
>
>
> Just to be clear: we're talking about the templating language used to
> generate XML out of (usually flowscript) data, right?
yes
> I'm asking (although I know ;-) because the requirements of a *final
> presentation" templating system might be fairly different - at present
> the mainstream way (AFAIK) is to use XSLT to generate HTML, WML or
> whatever, but for many people "templating" in the context of a webapp
> means roughly "edit pages with DreamWeaver, put some special codes and
> let the templating engine insert the data".
>
> Maybe we should call JXTemplate our "XML templating engine" to avoid any
> confusion.
good idea.
>
>> ...So, how do we continue to meet all these requirements?
>>
>> A.) Rewrite/refactor JXTemplate
>> - break it up in smaller, easier understandable/maintainable pieces
>> - deprecate #{} syntax and make expression languages plugable as
>> Sylvain suggested
>> - investigate the performance problems (I guess there are only
>> problems if macros are used)
>> - add the missing things from above...
>
>
> Sounds good if people are willing to do it.
;-)
at least we have a common understanding.
>
> Don't know enough about the other options, but I like this idea:
>
>> ...In my opinion we should write JXTemplate 2.0 which would be from
>> the user's POV as similar as possible to 1.0.
>> Technically this could be a complete rewrite (use garbage, tempo or
>> really from scratch) or at least a major refactoring...
>
>
> It would be (of course) good to include automated tests as well, using
> anteater for example, as this is a critical component
yes, very important
>
>>
>> Calling it JXTemplate is better for marketing reasons because it shows
>> more stability than telling our user base that they should use
>> something completly different in the future. Calling it differently
>> gives another impression than incrementing version numbers.
>
> +1
--
Reinhard
Re: Templating Engine - Next steps?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 1 nov. 04, à 17:30, Reinhard Poetz a écrit :
> After a lot of mails talking about expression languages and templating
> enginges I try to summarize the current state of our discussion. I
> see following requirements so far (in brackets you find the name of
> the person that brought up the requirement):..
Just to be clear: we're talking about the templating language used to
generate XML out of (usually flowscript) data, right?
I'm asking (although I know ;-) because the requirements of a *final
presentation" templating system might be fairly different - at present
the mainstream way (AFAIK) is to use XSLT to generate HTML, WML or
whatever, but for many people "templating" in the context of a webapp
means roughly "edit pages with DreamWeaver, put some special codes and
let the templating engine insert the data".
Maybe we should call JXTemplate our "XML templating engine" to avoid
any confusion.
> ...So, how do we continue to meet all these requirements?
>
> A.) Rewrite/refactor JXTemplate
> - break it up in smaller, easier understandable/maintainable
> pieces
> - deprecate #{} syntax and make expression languages plugable as
> Sylvain suggested
> - investigate the performance problems (I guess there are only
> problems if macros are used)
> - add the missing things from above...
Sounds good if people are willing to do it.
Don't know enough about the other options, but I like this idea:
> ...In my opinion we should write JXTemplate 2.0 which would be from
> the user's POV as similar as possible to 1.0.
> Technically this could be a complete rewrite (use garbage, tempo or
> really from scratch) or at least a major refactoring...
It would be (of course) good to include automated tests as well, using
anteater for example, as this is a critical component
>
> Calling it JXTemplate is better for marketing reasons because it shows
> more stability than telling our user base that they should use
> something completly different in the future. Calling it differently
> gives another impression than incrementing version numbers.
+1
-Bertrand
Re: Templating Engine - Next steps?
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> After a lot of mails talking about expression languages and templating
> enginges I try to summarize the current state of our discussion. I see
> following requirements so far (in brackets you find the name of the
> person that brought up the requirement):
>
> - control structures like for/each, if, choose (RP)
what bugs me is the verbosity of choose/when/otherwise to implement
if/else semantics. jx control statement syntax was based on xslt. Most
of my developers do not know xslt and they get really surprised with "no
else for if? really?"
> - call methods in a _simple/natural_ way on passed objects (RP)
> - stream objects (DOM, XMLizable, ...?) (RP)
> - define macros/taglibs (see cForm macros) (RP)
other examples:
- xmlization of a string
- wikification of a string
- special date formatter that renders all past dates red
so one thing is macros, other are pluggable "pretty printers"
> - works as a Transformer (SAX pipeline) (GP)
> - Ability to directly produce SAX events, for efficency reasons. (SW)
> - one default expression language (CZ)
> it thing most people prefer the "dotted" JEXL syntax
I prefer Jexl although I found one use case where Jexl could not handle:
jx:for in macro that has a variable var name:
> <jx:forEach var="${item}" items="${items}" varStatus="status">
> <colouredRow rowNo="${status.index}" odd="floralwhite" even="#eaeaea">
> <td align="right" style="background: floralwhite; width: 1px">
> <nobr>
> <a href="javascript:void(0);" onclick="return show( #{./id} );" onmouseout="nd();">
> <img src="/nTer/confadd_ov.gif" border="0" style="vertical-align: middle" alt="Akcja"/>
> </a>
> <jx:if test="${tags.additionalRowAction != null}">
> <jx:eval select="${tags.additionalRowAction}"/>
> </jx:if>
> </nobr>
> </td>
> <jx:eval select="${tags.resultRow}"/>
> </colouredRow>
> </jx:forEach>
The only way to dereference something declared with var="${item}" is to
use #{./id}
> - support for additional expression languages (SW)
what are other known expression languages that we could incorporate?
> - use the TemplateObjectModelHelper as Cocoon wide object model (CZ)
>
> and not to forget
>
> - cacheability (RP)
> (BTW, has caching been implemented to everybodies satisfaction or
> are there open issues or possible improvements? Leszek?)
Cacheability works fine but I must confess the declaration syntax was
not well thought be me. Currently you can place jx:cache-key attribute
on ANY node of your template. Every node is also being scanned for jx:*
attributes. In future implementation I propose something like
<jx:processing-instruction name="cache-key" value=${cacheKey}"/>. This
also allows for new processing instructions with ease.
> and one issue that bugs me for a long time ...
>
> - add support for dynamic attributes - similar to xsl:attribute (RP)
Yes yes yes!
> - o -
>
>
> So, how do we continue to meet all these requirements?
>
> A.) Rewrite/refactor JXTemplate
> - break it up in smaller, easier understandable/maintainable pieces
> - deprecate #{} syntax and make expression languages plugable as
> Sylvain suggested
> - investigate the performance problems (I guess there are only
> problems if macros are used)
> - add the missing things from above
I would go for this one. What makes the code hard to read is:
- everything put into one file. There is not other source file in cocoon
that has 160kB
- two languages handled paralelly which makes the code really ugly.
> In my opinion we should write JXTemplate 2.0 which would be from the
> user's POV as similar as possible to 1.0.
> Technically this could be a complete rewrite (use garbage, tempo or
> really from scratch) or at least a major refactoring.
>
> Calling it JXTemplate is better for marketing reasons because it shows
> more stability than telling our user base that they should use something
> completly different in the future. Calling it differently gives another
> impression than incrementing version numbers.
I agree, it is very important that we do not deprecate another view
rendering mechanism. Until now users do not understand why XSP has been
killed.
There is one more thing. Right now I find this construct useful:
macros.jx:
<jx:set var="tags" value="${java.util.HashMap()}"/>
<jx:macro name="dynamic-tag">
<jx:parameter name="id"/>
<jx:set var="ignored" value="${tags.put(id, macro.body)}"/>
</jx:macro>
<jx:macro name="myMacro">
render something there
<jx:if test="${tags.additionalInfo != null}">
<jx:eval select="${tags.additionalInfo}"/>
</jx:if>
</jx:macro>
someView.jx:
<jx:import uri="macros.jx"/>
<dynamic-tag id="additionalInfo">
render something here
</dynamic-tag>
<myMacro with="some param"/>
This is a poor man's implementation of a templating solution that PHP
users widely use. It would be nice to have it directly in the template
language.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65