Re: [RFC] Plugable Expressions

[Leszek Gawron]

Finally after 3 weeks I have some spare time that I can assignate for JXTG.
Daniel Fagerstrom wrote:
I have implemented a first version of plugable expressions as discussed 
in: http://marc.theaimsgroup.com/?t=109903957300001&r=1&w=2 and the end 
of http://marc.theaimsgroup.com/?t=109901879000001&r=1&w=2. I use them 
in the refactored JXTG but in a way that (hopefully) is completely 
invisible for the user.

I would like to get your feedback on the approach, intefaces, 
implementation etc. So that we can improve it and move it to the core as 
a standard interface for expression usage when it is good enough.

Src
===
The code can be found in (in trunk):
 
src/blocks/template/java/org/apache/cocoon/components/expression/expression
tests in:
 
src/blocks/template/test/org/apache/cocoon/components/expression/expression

A FOM like context (slight modification of TemplateObjectHelper in 
scratchpad):
 src/blocks/template/java/org/apache/cocoon/environment/environment
And some test:
 src/blocks/template/test/org/apache/cocoon/environment/environment
the code looks much clearer now.
Expression
----------
The Expression interface looks like:
public interface Expression {
   public Object evaluate(ExpressionContext context) throws 
ExpressionException;
   public Iterator iterate(ExpressionContext context) throws 
ExpressionException;
   public void assign(ExpressionContext context, Object value) throws 
ExpressionException;

   public String getExpression();
   public String getLanguage();
   public void setProperty(String property, Object value);
   public Object getNode(ExpressionContext context) throws 
ExpressionException;
}

evaluate, iterate and assign should be rather obvious. getExpression and 
getLanguage is mainly for making reasonable error messages possible.

I'm less certain about setProperty that I mainly added to be able to 
handle the lenient property for JXPath, but it is not certain that 
properties should be part of expressions, maybe they should be part of 
the factory instead.

I like the getNode method even less and would like to get rid of it. I 
introduced it as JXPath both has a getNode method that returns the raw 
object pointed to and a getValue that does some extra work on it, (like 
the irritating xsl:value-of stuff on DOM). Now Expression.evaluate 
basically does JXPath getValue and Expression.getNode does JXPath getNode.
Could you describe the difference in more detail?
I would prefer to get rid of the Expression.getNode method and have Let 
Expression.evaluate basically call JXPath getNode. But I don't know 
enough about the consequances for e.g. JXTG, any opinions?
I see only one place now that could be problematic:
<jx:set name="var" value="something"/>
vs.
<jx:set name="var">something</jx:set>
Both are allowed and both should be treated differently.
JXPath and Jexl
---------------
I have implemented a JXPath and Jexl variant of the intefaces.
Questions
=========
* Is the design reasonable?
* Does it work for other ELs?
There is only one more EL used in cocoon: XReporter EL. Should we take 
it into account?

Daniel, what are your current plans for JXTG refactoring? I do not quite 
know what to start with now.

--
Leszek Gawron                                      [EMAIL PROTECTED]
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65