cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting
Date Sun, 27 Feb 2005 22:46:16 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. And these are the ones we use everywhere in Java code. I 
may have not said the same thing for objects that have no commonly-used 
Java counterpart (e.g. a WebContinuation), but this isn't the case here.

> Although it really doesn't matter much to me since I don't use Cocoon, 
> it appears to me to be in the interest of the Cocoon community to 
> reimplement the "unrestricting" of the FOM without using direct Rhino 
> wrappers of o.a.c.environment.Request, etc Java interfaces.

Ok, thanks for you opinion.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message