Ugo Cei wrote:<snip/>
Sylvain Wallez wrote:
Can you explain in more details what's the purpose of the jxpathContext here and where its value come from? Adding a dependency on JXPath so high in Woody interfaces doesn't seem good to me.
Ok, I understand. I encountered a somehow similar problem and came to the conclusion that what we need is actually to have <wd:selection-list> a pluggable component.
We could then have <wd:selection-list type="default|flow-jxpath|javascript|whatever"> and the attributes and content of this element be the configuration of the selection list. We can then have the FlowJXPathSelectionListBuilder be Contextualizable to give the Avalon Context to the FlowJXPathSelectionList it creates.
The flow context is then available through FlowHelper.getContextObject(ContextHelper.getObjectModel(avalonContext)).
This would avoid passing along the context object and also use it in situations other than generateSAXFragment() such as during form validation (for closed enumerations).
What do you think?
Sylvain
Maybe somewhat OT, but wouldn't it be a good idea to define an API for using expression languages access java objects. After all, there starting to be quite a few components in Cocoon that uses JXPath or other expression languages. An expression language component would make it easier to write and support such components and it would probably make the use of expression languages more standardized among components.
JEX http://www.plotnix.com/jex/index.html is an example of what such an API could look like. JEX was added to jakarta-commons-sandbox but didn't take of, IIRC people thought that it was better to use BSF, but IMO something like JEX would be usefull for using expression languages in Cocoon.
WDYT?
/Daniel
