cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject [RT] CTemplate
Date Sat, 26 Feb 2005 13:02:44 GMT
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:


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:


for the default EL ;).

We should also IMO remove the Java package mechanism from the 
environment in CTemplate, i.e. the possibillity to do:


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.


Following the order in


Could be kept as is.


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.


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 

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.

if, choose

if and choose are OK as is IMO.


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.


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


An xsl:attribute like construction would be usefull. Seem tricky to 
implement though.

caching directives

Have not spent much thought about caching directives.

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 

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.

                    --- o0o ---



View raw message