Leszek Gawron wrote:
Leszek Gawron wrote:
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.
Plugging one expression parser into the Parser is not enough. Most of
users will still want to use both JEXL and JXPath in one template as
the functionality of both maps well on different areas of object model.
Sorry, I'm only making noise here :). I found a proper thread.
No, I use faulty terminology, I didn't mean expression parser but rather
string template parser (or whatever we should call it).
For those who don't remember the discussions (which seem to include me
;) ), what we are talking about is the "string templates" in an template
language, i.e. the character data in elements and the value of
attributes. In JXTG string templates looks like:
"foo ${cocoon.continuations.id} bar #{2+3}"
The string template parser split the string into strings "foo " and "
bar " and expressions "cocoon.continuation.id" and "2+3". The
expressions are in turn sent to the expression parsers of Jexl and
JXPath respectively. And the result is a sequence (or iterator over)
strings and compiled expressions.
The idea now is to make this plugable so that one can replace the JXTG
default string parser mechanism with plugable ones. What we more
specifically have in mind is to have a new default string template
parser that use "{}" to embed expressions (following attribute value
templates in XSLT, with '{{' and '}}' for escaping '{' and '}') and that
let the expression parser (using the ExpressionFactory) of the plugable
expressions in template handle the expressions. This will lead to
expressions like:
"foo {jexl:cocoon.continuations.id} bar {jxpath:2+3}"
where "jexl" and "jxpath" are defined in a configuration file. The
plugable expressions also allow for a default exprssion language, so
that you just need to write e.g. {cocoon.continuations.id} if you chosed
Jexl as default template language.
Adding a more technical note: It is mainly the classes and interfaces in
o.a.c.template.expression that need to be generalized. The JXTExprssion
class both contain a parsing mechanism and embeds the compiled
expression with some type conversion stuff. When we add the conversion
stuff we can hopefully have better separated concerns and remove all the
use of the JXTExpression in the script instruction classes and use
converters and expressions instead.
At a later point we should move plugable expressions, string template
parsing and coversion to core and use it everywhere in Cocoon, to make
Cocoon more coherent while we at the same time can keep it back
compatible by keeping old behaviour as plugins.
/Daniel
