Daniel Fagerstrom wrote:
Christopher Oliver wrote:
<snip/>
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.
Yes, extensive community discussions: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107996911721844&w=2 http://marc.theaimsgroup.com/?t=108720735900003&r=2&w=2
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?
Okay, rather than trying to rewrite history and spread some FUD, tell me where the incompatibility is. My changes *added* some features and did *not* remove anything.
And tell me also how the previous JS API was different from the Java API? It *was not*. It was just a limited copy of the Java environment API. So this story about different ways of expressing things in different languages is just a wrong argument. What I did is just exposing all methods of the underlying Java objects to the JS code. That's all.
I admit however there is a possibly incompatible change: as JavaBean properties of the underlying objects are now exposed as JS properties, those may take precedence over the request parameters having the same name. I'm of course ready to fix this, so that there is absolutely no incompatibility.
--- 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.
If the initial design shows some weak points, why not fix it?
The mixing of attribute and map name spaces in FOM is, as Chris said a usablity tradeof and a common JS idiom.
I don't care about "common" idioms when they make you less confident about the code you write and potentially make you loose hours because of stupid things like the "form.submit" I explained earlier.
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}
Wrong, wrong, wrong and wrong. You can still write the abbreviated form. Rather than criticizing, please try it by yourself and look at the code.
--- 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.
Throwing away? Please stop that FUD. I'm trying to improve things and care for backward compatibility.
You know what? I'm fed up with this discussion, and will start writing a new implementation of the JS flowscript engine. People will have the choice. And Chris will stop popping up as soon as someone touches his code.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
