Sylvain Wallez wrote:
Shouldn't this component be called just JXPathSelectionList? There's no reason why it should be called from the Flow only, is there?
Yes, there is, since the xpath expressions apply to the flow view data object (I prefer "view data" to "context object" as there are already too many "context" objects in Cocoon).
I see, but maybe it would be useful to use data coming from somewhere else. I'll have to reflect some more about this.
Maybe we could define the context object for the xpath expressions using an input module? Or have an AbstractXPathSelectionList and have FlowXPathSelectionList extend it?
That's why FlowXPathSelectionList is so simple.
Understood.
What about tests? ;-)
Well, awaiting your commit ;-)
See FlowJXPathSelectionListTestCase ;-). By the way, as you wrote above, there are too many contexts in Cocoon. In order to pass the "view data " to Cocoon, I had to put that inside a flowContextObject which in turn is put inside a Request which in turn is put inside an objectModel which in turn is put inside a contextObjectModel which is used to build the Context. Can you say "matrioska"? ;-)
You're right. And I was thinking of "promoting" the view data object as a member of the object model (it's today a request attribute). This should not break compatibility as this is hidden inside FlowHelper, and would speed up access by avoiding the intermediate access to the request object.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
