cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: [RFC] Plugable Expressions
Date Fri, 21 Jan 2005 14:38:44 GMT
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: and the end 
> of 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"/>

<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                            
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message