cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] CTemplate
Date Sat, 26 Feb 2005 16:10:54 GMT
Leszek Gawron wrote:

> Daniel Fagerstrom wrote:
>
>> 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 make the default language easily configurable.

It is, see 
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/template/WEB-INF/xconf/cocoon-template-expression.xconf?view=markup

And we can also use the "jx:language="jxpath" on the root element" that 
Vadim reminded about.

> We won't reach a consensus in the battle Jexl vs. JXPath. 

No, but the Jexl side is wrong ;)

>> 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 convertors)
> - 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}"
>       pattern="${Packages.com.myproject.Constants.WEEK_DATE_FORMAT}"/>
> (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) 

Yes I know about this, and it is intensional ;) As long as one can solve 
those things with more or less ugly Java hacks within the template no 
one will be motivated enough to find clean and easy to understand 
solutions for important use cases. And this means that we don't care 
enough for template authors with limited or no Java skills.

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

Might be, but I'm not particulary found of the idea of adding the 
bloated and FS ridden input modules to the template object model. It 
will certainly not make Cocoon easier to understand for newbies.

If we can throw out the meta modules and other FS from core to some 
block with huge warning signs on, and just keep the input modules that 
just returns environment objects and the like, whothout to much fancy 
extras. In that case it would be OK for me to build template object 
model from input modules. But just merging input modules into the object 
template model without working on tidying things up first makes the 
result far to complex for my taste. But I'm not going to give any -1, 
just complaining violently ;)

<snip/>

>> 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.
>
> 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. 

I know that you want assignment. In the end I think that it is about 
personal taste and what you think should be part of the view and what 
should not. We see what people think and decide based on that.

And even if we decide to not have an assignment, no one can hinder you 
from sending a counter object from the control to the view, so you will 
be able to hack around anyway. But IMO we should keep CTemplate minimal.

> 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 
> environment.
> - 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. 

Seem to complicated to me.

>> 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. 

I know. I find ${node} slightly to powerfull as it not is particulary 
obvious from what it looks like that it can generate XML and would 
(maybe) like to restrict it to only text generating expressions. In that 
case we would need jx:out for generating XML. But that is not to 
important to me.

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

No.

<snip/>

>> 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. 

Ok

>> 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}"/> 

Seem better.

/Daniel



Mime
View raw message