cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting
Date Mon, 28 Feb 2005 01:55:18 GMT
>Christopher Oliver wrote:
>>> 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).

After all, if you really want to use the Java API, you can now use Java 
Flow right?

-- Chris

View raw message