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 Sun, 27 Feb 2005 22:30:27 GMT
>> This is a tradeoff: by "combining" properties you get easer access to 
>> commonly used properties, but however at the cost of overloading the 
>> identifiers at times. Note that it's always possible to provide an 
>> "escape" mechanism to disambiguate such cases, even if DOM didn't do 
>> that in this case.
>>> And that's what I call, maybe not adequately, "inconsistencies". 
>>> Consider the JS wrapper for the request object. It has a "remoteUser" 
>>> property because of the request.getRemoteUser() method. Now what 
>>> happens if "http://foo/bar?remoteUser=root" <http://foo/bar?remoteUser=root>

>>> <http://foo/bar?remoteUser=root> is called? Your application is 
>>> fooled in believing that a super user issued the resquest!!
>> Actually, that's FUD. There is no "remoteUser" property in FOM_Request 
>> corresponding to Request.getRemoteUser().
>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".

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.

-- Chris

View raw message