cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Templating Engine - Next steps?
Date Tue, 02 Nov 2004 14:49:43 GMT
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:

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 ;)


View raw message