cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: Templating Engine - Next steps?
Date Mon, 01 Nov 2004 19:43:31 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)
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 

There is one more thing. Right now I find this construct useful:
<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 name="myMacro">
	render something there
	<jx:if test="${tags.additionalInfo != null}">
		<jx:eval select="${tags.additionalInfo}"/>

<jx:import uri="macros.jx"/>
<dynamic-tag id="additionalInfo">
	render something here
<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 

Leszek Gawron                            
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message