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 the FOM)]
Date Sun, 27 Feb 2005 09:33:34 GMT
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.

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" is called? Your application is 
fooled in believing that a super user issued the resquest!!

The result of this is that you always have to refrain using the 
properties in favor of method calls in order to be really sure of what 
data you access, and therefore loose the apparent simplicity of properties.

An acceptable JS wrapper, less verbose that the standard Java/JS mapping 
would be one that clearly separates the various property spaces, e.g. 
"request.parameters.foo". But implementing this causes other problems 
(see below).

> At any rate, I fail to understand how a massively non-backward 
> compatible change can be made which was not even relevant to the 
> subject voted on.
>
> As I understand it there was a vote to "unrestrict" the FOM, thereby 
> removing the contracts from (2) above. AFAIK this could have been 
> implemented easily without causing backward incompatibility in 
> accessing the FOM from JS/Jexl/JXPath.


The multiple expression languages are also a problem, especially if you 
consider that each one has its own preferred way of expressing things. 
Starting from one single class, you have to learn not only the standard 
mapping to Java objects provided by each language, but also all the 
different specific mappings provided for each of the object model 
objects. IMO a nightmare for users.

> My $0.02,


Thanks for them. It led me to expand on my reasons for this change.

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