cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting
Date Mon, 28 Feb 2005 14:19:58 GMT
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 }


Mime
View raw message