Christopher Oliver wrote:
Christopher Oliver wrote:
<snip/>
Mmmh... you're right, there _wasn't_ such a property before my changes. This explains the lengthy wrapping code that was in FOM_Request that exposed only functions and no properties except the request parameters (or attributes for session and context).
Now this throws away one of the nice things that Rhino provides us which is shorter dotted notation for JavaBean properties. And that's what I find confusing: once someone has understood how Java objects are mapped to JS objects, he needs next to forget this knowledge and learn that request, session and context have to be used in a special way.
JS objects can and do exist without directly "wrapping" Java objects.
If you had accepted the original design which made FOM_Request, FOM_Session, etc, first-class JS objects (i.e. _not_ "mapped" versions of the Java objects) then there isn't any special knowledge to "throw away".
Yes there is, because the reference objects in the case of FOM are the *Java* objects.
Are they? At least to me the concepts of Request, Session, Request Parameter, Session Attribute, etc, exist independently of those Java interfaces (in fact the Servlet API presents most of the same concepts with different interfaces). Stefano and Ricardo took the time and effort to define a JS API for those concepts, which included accessing Request parameters as JS properties, and so on. I don't see anything wrong with their API and I don't see any reason to convert it to the Java API (and there are plenty of reasons not to - for backward compatibility and ease of use, at least).
+1
FOM as it was until recently was based on extensive discussions in the community http://marc.theaimsgroup.com/?t=105401789500001&r=1&w=2, http://marc.theaimsgroup.com/?t=105572173100003&r=1&w=2,
http://marc.theaimsgroup.com/?t=105588670600005&r=1&w=2,
http://marc.theaimsgroup.com/?t=105794471900001&r=1&w=2
and certainly many more threads.
In the [RT] FOM, Stefano stated:
The FOM is the Flow Object Model. In my vision, it's the server-side equivalent of the DOM.
i.e. it is supposed to be a JS model of relevant Cocoon environments following JS idioms. It is not intended to be as close as possible to the Java servlet. We agreed about that back then and I still find the arguments from those discussions valid.
Furthermore our users have trusted in FOM being a stable contract and based their applications on them, we should have _really_ strong reasons for breaking this trust. Leszek, to take just one example estimates that it will take him a couple of days to adapt his code to the new FOM, http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110942199227672&w=2. Multiply this with the number of users of Flow. Are our reasons strong enough to create that amount of bad will and distrust?
--- o0o ---
Chris implemented Stefano's and Richardo's (and the rest of the communities) design http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105401786813250&w=2. The so called "inconsistencys" are part of the initial design as can be seen there. The mixing of attribute and map name spaces in FOM is, as Chris said a usablity tradeof and a common JS idiom. Furthermore Chris made it possible to use parts of FOM in a systematic way from both Jexl and JXPath in JXTG. So that you could do things like:
${cocoon.session.user.id}
#{$cocoon/session/user/id}Now after the "improvement" you must do:
${cocoon.session.getAttribute('user').id}
#{getAttribute($cocoon/session, 'user')/id}instead.
--- o0o ---
IMO we should go back to the earlier behaviour of FOM, that our users depend on and fix whats broken there instead of just throwing everything away.
If we can find way to simplify the FOM code, thats excelent, but not at the cost of usabillity and compability.
Furthermore we should IMO factor out FOM from flowscript to general environment handling, as script style (JS) environment embeding is needed for use with expression languages in templates and possibly also in the sitemap.
After all, if you really want to use the Java API, you can now use Java Flow right?
Exactly, its fine that Cocoon is implemented in Java, but we shouldn't design flowscript, template, sitemap and so on under the assumption that Java APIs are natural and familiar for all our users.
/Daniel
