Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I don't think this should break much code, as that object (which BTW I prefer to name "view data" rather than the ambiguous "flow context" -- we have enough contexts in Cocoon) is supposed to be a JS object. And a JS object can easily be turned into a Map by associating property names to Map keys. We could even have a JSObjectMap that wraps a Scriptable as a Map.
Can I consider this a +1 to make the contract more strict? :)
Don't you think "view data" should support Java Beans as well?
No :) Currently we look if "view data" is either a map of objects (beans) or a single bean - and this looks ugly and unnecessary to me.
Flow and JXTG was designed to work in a smooth way both with JXPath and Jexl. We all agree about that it would have been better to choose one of them, but we don't agree at all about which of them. So for the forseeable future we have to, like it or not, live with both of them.
Now if you use Flow/JXTG with JXPath it is rather reasonable to send a single bean or DOM from flow to JXTG, it will be used as the context object for your XPath expression. From an XPath POV this is more natural than using variables. I have IIRC used it a number of times, and other users can have done it as well.
I'm strongly against breaking users code due to minor, (and from an JXPath POV rather unclear), elegance issues.
I have done an effort with the o.a.c.components.expression stuff in the template block to isolate the various quirks in the invidual expression languages behind a common interface so that we don't have to see it in the rest of the code. IMO we should do the same for the environment handling. Then we can have one factory like o.a.c.environment.FlowObjectModelHelper.getFOMExpressionContext that sets up the context so that it works for all expression languages. If that factory happens to contain some ugliness it shouldn't matter as it is issolated from the rest of the code.
We can move o.a.c.components.expression to core as soon as you and others have reviewed it (see http://marc.theaimsgroup.com/?t=110595829700001&r=1&w=2).
Why not always have a map - if you want to put a single bean into the data then make a map with one entry. But imho it feels wrong that depending on what you put into the view data, you access it differently from e.g. jxtg
Does it still feel wrong with the JXPath POV in mind?
/Daniel
