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 Sun, 27 Feb 2005 21:48:02 GMT
Christopher Oliver wrote:

>
>> Christopher Oliver wrote:
>>
>>> Sorry to pick on Sylvain again, but he consistently exhibits a 
>>> common behavior of Java programmers with respect to JavaScript. 
>>> Because JS syntax is so similar to Java they seem to feel a JS API 
>>> is somehow "better" the more it resembles what it would look like if 
>>> it was written in Java.
>>>
>>> The "special wrapper" objects in the FOM served two purposes:
>>>
>>> 1) The enforced the FOM contracts which were voted on by the Cocoon 
>>> community (note that although I implemented it I did _not_ define 
>>> those contracts).
>>> 2) They made the underlying Cocoon Java API (Request, Session, etc) 
>>> easier to access in JS (and in Jexl whose syntax is identical to JS).
>>>
>>> It should be obvious by looking at the history of JSP (which 
>>> migrated from plain Java to the JSTL EL (implementd by Jexl). that a 
>>> JS like approach can be preferable to Java in some cases.
>>>
>>> Opinions may vary, but to me JS is _actually_ a different language 
>>> than Java and and an API that is provided in both languages should 
>>> not be required to be identical in every respect (e.g. JavaFlow 
>>> versus JS flow, Java DOM versus JS DOM, etc).
>>>
>>> Sylvain describes these differences as "inconsistencies", however I 
>>> rather regard them as appropriate differences given the target 
>>> languages (which in the case of JS will be appreciated by 
>>> experienced JS programmers).
>>
>>
>>
>> The inconsistencies are not in the language itself, but IMO in the 
>> way it has been used from day one in browsers, and which has 
>> "infected" its use everywhere else afterwards.
>>
>> This problem is that it's rather common practice in JS to mix 
>> properties coming from different naming contexts on a single object. 
>> Consider the <form> object in HTML: it has a submit() function which 
>> submits the form. It also has properties added for all form input.
>>
>>  
>>
>> Now what happens if your form has an <input name="submit">? You can 
>> no more call form.submit() as the function property has been replaced 
>> by the HTMLInputElement object. I've hit this several times and spent 
>> hours finding out why my form wasn't working.
>>  
>>
> 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> 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.

> If "request.remoteUser" is defined it is always the request parameter
>
> If you want Request.getRemoteUser(), you have to call the function..
>
> BTW, you did correctly identify a bug in FOM_Request.getIds(). 
> However, that wouldn't be noticed unless you did something like:
>
> for (i in request) {...}


Yup.

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