cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject [RT] CTemplate
Date Sat, 26 Feb 2005 13:02:44 GMT
Now that we have decided to call JXTG CTemplate in the future 
http://marc.theaimsgroup.com/?t=110908866100002&r=1&w=2, 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 
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf, but without to 
much fundamentalism.

See http://wiki.apache.org/cocoon/Templates 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 
(http://marc.theaimsgroup.com/?t=110595829700001&r=1&w=2) 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 also IMO remove the Java package mechanism from the 
environment in CTemplate, i.e. the possibillity to do:

${java.util.HashMap()}


and the like, as discussed in 
http://marc.theaimsgroup.com/?t=110907735600005&r=1&w=2. 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 
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html

template
--------

Could be kept as is.

import
------

The current import construction must be performed during template 
execution (see 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110659947823196&w=2), 
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.

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 
http://marc.theaimsgroup.com/?a=103818032900001&r=1&w=2 and the end of 
http://marc.theaimsgroup.com/?t=110623014500003&r=1&w=2 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.

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.

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 
http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2.

macro, eval, evalBody
---------------------

The macro stuff should be replaced with Leszek's new constructions 
http://marc.theaimsgroup.com/?t=110940836200001&r=1&w=2.

attribute
---------

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 http://wiki.apache.org/cocoon/Templates). 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.

                    --- o0o ---

WDYT?

/Daniel



Mime
View raw message