cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: [RT] CTemplate
Date Sat, 26 Feb 2005 14:39:46 GMT
Daniel Fagerstrom wrote:
> Now that we have decided to call JXTG CTemplate in the future 
>, is it a good 
> opportunity to discuss what CTemplate should become.
> IMO CTemplate should be close to JXTG but we should remove all of the 
> peculiarities and make it as side effect free as possible. And as simple 
> as possible. I also think that we should try to follow the principles 
> from StrinngTemplate 
>, but without to 
> much fundamentalism.
> See for references to earlier 
> discussions about templates.
> Expression handling
> ===================
> We should get rid of the confusing #{}, ${} syntax. I would prefer using 
> {} as in XSLT. With the new pluggable expressions 
> ( one can use:
> {jxpath:$a+$b}
> or
> {jexl:a+b}
> when wanting to chose expression language (EL). We need to decide if 
> JXPath or Jexl should be the default EL, so that one just need to write:
> {$a+$b}
> for the default EL ;).
We should make the default language easily configurable. We won't reach 
a consensus in the battle Jexl vs. JXPath.

> We should also IMO remove the Java package mechanism from the 
> environment in CTemplate, i.e. the possibillity to do:
> ${java.util.HashMap()}
Note that this is not feature you remove. You won't be able:
- to construct java objects (which you should not be)
- to call static methods (which if properly used could be replaced with 
- to access constants defined in classes:
public class Constants {
   public final static String WEEK_DATE_FORMAT = "['T'ww] yyyy-MM-dd, E";
and then:

<jx:formatDate value="${date}"
(this is not a problem of format date if you want to point out 
convertors - it's the general problem of using constants in template)

maybe this could be replaced by the feature of merging input modules 
into template object model.

> and the like, as discussed in 
> If there are 
> important use cases where one need to create Java objects, we should try 
> to find cleaner ways to solve them.
> Instructions
> ============
> Following the order in 
> template
> --------
> Could be kept as is.
> import
> ------
> The current import construction must be performed during template 
> execution (see 
> instead of during template compilation. This makes macros slower. I 
> would like to remove the dynamic aspects of imports so that it works 
> like include or import in xslt.
Agreed. There is no single (and reasonable) use case I can think of that 
would require dynamic imports.

> set
> ---
> The current behaviour of set is somewhat weird as it works as an 
> asignement in the current context but you cannot affect a variable that 
> is created outside the current context, e.g. outside a loop (see 
> and the end of 
> for examples and 
> discussion).
> There are two reasonable solutions:
> * Having it declarative and replace set with a let (or declare, define, 
> variable etc) that just defines the variable, no assignement anymore 
> (like in e.g. XSLT).
> * Replacing set with declare and assign, where the first introduces a 
> variable with possibly an initial value and an assign that change the 
> value of an allready existing variable.
> I prefer the first solution.
As long as we do not have a solution for "looping problem" (which is not 
that rare - got into hacks myself many times) I opt for the second 
solution. To keep the template as side effects free as it's possible I 
would go for a solution that I proposed some time ago:

Initially the object model consists of 2 levels:
- root level that contains all cocoon.* environment beans - you cannot 
do a declare, assign here. This could prevent from modifying the 
- first template level. empty at start of template generation. This is 
the level for declaring template variables.

I do not know if that helps anything.

> if, choose
> ----------
> if and choose are OK as is IMO.
> out
> ---
> It is unclear to me if out is needed. Possibly we could be stricter 
> concerning output of XML in CTemplate so that an expression whithin a 
> text only is allowed to return text. And then out should be used for 
> outputing XML.
Why do you need jx:out to output xml?
${node} is enough to generate sax events automatically.

Are you suggesting that jx:out should automatically parse text variables 
and generate SAX events?

> forEach
> -------
> forEach is to complicated for my taste, I would prefer to only have the 
> select attribute as in XSLT, but I know to little about the Jexl use 
> cases to know if it is realistic.
> formatDate, formatNumber
> ------------------------
> The formating instructions should IMO be removed and replaced with the 
> convertor mechanism discussed in 
> macro, eval, evalBody
> ---------------------
> The macro stuff should be replaced with Leszek's new constructions 
summing up:
jx:macro defines, jx:call invokes
no more jx:eval
jx:evalBody stays as is.

There is a case with invoking macros only by creating an element with 
macro's name. Sylvain has got some comments about that in paralell thread.

> attribute
> ---------
> An xsl:attribute like construction would be usefull. Seem tricky to 
> implement though.
doable with some kind of extended ContentHandler that
- introduces a new "attribute" event instead of plain startElement
- caches element and characters emiting until we are sure there will be 
no more attributes generated.

> caching directives
> ------------------
> Have not spent much thought about caching directives.
right now anywhere in template you can do:

<someElement jx:cache-key="${key}"/>

This is my fault. It slows down template parsing (all jx:* attributes 
have to be stripped out). Could be much better implemented with:
jx:processing-instruction name="cache-key" value="${key}"/>

> Attribute templates
> ===================
> We have also discussed attribute driven template languages (ATL) (see 
> references in Everything above 
> applies to such an ATL as well, but there might be need for some extra 
> instructions in an ATL as an ATL constrains how one can write templates 
> further.
> We could even be so radical that we decide that CTemplate should be an 
> ATL. But I prefer having a separate ATL generator. I need more 
> experience from writing ATL templates before I'm convinced that it is 
> the way to go for all templating needs.
Cannot comment anything useful :)

Leszek Gawron                                                 MobileBox                    

View raw message