cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting
Date Mon, 28 Feb 2005 13:27:58 GMT
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


Mime
View raw message