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: Status of JXTemplate refactoring
Date Wed, 07 Sep 2005 10:33:34 GMT
Leszek Gawron wrote:
...

> OK. So we have pluggable expression parser.

Cool! Great that you work on this.

Would still rather call it StringTemplateParser or StringParser, 
following the arguments from my previous post:

  "asdf {2+3} sdfhg"

is a string template,

  "2+3"

is an expression.

> I have tested it a bit but new test cases are a must.
>
> If you want to try it out replace one line in:
> src\blocks\template\trunk\WEB-INF\xconf\cocoon-template.xconf
>
> from:
> <component 
> role="org.apache.cocoon.template.expression.JXTExpressionCompiler" 
> class="org.apache.cocoon.template.expression.DefaultJXTExpressionCompiler"/> 
>

Would prefer JXTGStringParser, default isn't future safe, as we want to 
move to CTemplate.

> to
> <component 
> role="org.apache.cocoon.template.expression.JXTExpressionCompiler" 
> class="org.apache.cocoon.template.expression.NewStyleJXTExpressionCompiler"/> 
>

This could be DefaultStringCompiler or CTemplateStringCompiler.

> Unfortunately both versions cannot exist at the same time. To make 
> that happen I would have to extend DefaultScriptManager (to lookup 
> different JXTExpressionCompiler) and JXTemplateGenerator (to lookup 
> different ScriptManager). I wonder if there's a simpler solution for 
> that.

Hm, it is split into components in a somewhat strange way IMO. First, 
for things like the JXTExpressionCompiler where one have several 
implementations of the same interface, it is natural to use selectors 
(Avalon ones) in the component handling, take a look at the 
o.a.c.compnents.expression.** and its configuration file for examples. 
Second, it is somewhat over componentisized for my taste: Does the 
default instruction factory really be a component? Wouldn't be enough to 
give it an URL to the script configuration in its constructor. Same 
thing with the DefaultScriptManager, if you give it a name space, and a 
parser to its constructor, there is not that much need to make it a 
component. The parser could in turn be given an instruction factory and 
an JXTExpressionCompiler as arguments to its constructor.

In the end I think it will be simplest if the generator looks up the 
plugable components and the configuration files, i.e. the 
JXTExpressionCompiler and the instruction configuration file and maybe 
some more stuff and just pass these components to the other classes in 
the template framework.

The most natural thing would be to have a generic template generator 
that you just configure with what instuctions and what expression 
compiler you want. But people didn't want that level of flexibility so 
therefore such things need to be hard coded in the generator class.

In general, the main use for components is if one really know that one 
will need to be able to choose between several different implementations 
of the same interface at deploy time. And if one want to be able to use 
several implementations of the same interface at once in a plugable way, 
selectors is the way to go. Otherwise components are overkill.

> I assume we want to keep backward functionality.

Yes!

> Is it OK if I just create CTemplateGenerator extending current 
> JXTemplateGenerator?

Better, create a common AbstractTemplateGenerator and let both 
JXTemplateGenerator and CTemplateGenerator extend it.

/Daniel


Mime
View raw message