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
