cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Status of JXTemplate refactoring
Date Mon, 05 Sep 2005 20:38:27 GMT
Joerg Heinicke wrote:
> Hello,
> I was asked for a possible refactoring of the JXTemplateGenerator. 
> Somebody wants to provide only a very limited set of functionality to 
> his template writers: only JXPath (no JEXL), only one object model.
> He started with patching the version of JXTemplateGenerator coming with 
> 2.1.7. Simply extending it does not work because of to much private 
> stuff. But with the refactoring happened to the official 
> JXTemplateGenerator this also seems not to make much sense.

Redoing the refactoring work that Leszek and I already have done seem 
like wasting time.

> Now the questions: The refactoring happened only in the trunk, didn't 
> it?

It only happened in trunk, keeping a synchronized copy in the 2.1.x 
branch while refactoring didn't seem that fun. It would probably easy to 
port it to 2.1.x if anyone feel like doing it.

> How far is it pluggable,

Concerning instructions sets it is completely pluggable, take a look at 
the configuration and o.a.c.template.script.InstructionFactory and 

> how far are the above mentioned requirements supported?

Much of it is supported, but there is some refactoring work left to do.

Expressions are pluggable, see o.a.c.components.expression.**. There is 
only one common object model for all Expression implementations: 
ExpressionContext and the standard object model is created by 
o.a.c.template.environment.FlowObjectModelHelper and pluged in in the 
JXTemplateGenerator class.

But the actual expression parsing used in the template framework is not 
plugable yet. Take a look at the class o.a.c.template.script.Parser, it 
calls o.a.c.template.expression.JXTExpression for expression parsing. 
JTExpression recognice the ${} and #{} syntax and create the right kind 
of expression.

To make the expressions completely plugable within the template 
framework, we need a expression parser interface and we need to make the 
expression parser implementation plugable in the Parser.

> Is there any obvious problem using the template 
> block in Cocoon 2.1?


                   --- o0o ---

Further links about the template block design and discussions can be 
found at There was also an 
agreement that JXTG should be renamed to CTemplate and get a new name 
space. We had some discussion about what CTemplate should contain: Among other 
things it was supposed to have more plugable expressions.


View raw message