JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]

[Christopher Oliver]

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).

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.

My $0.02,
Chris

Antonio Gallardo wrote:
On Mie, 9 de Febrero de 2005, 12:06, Sylvain Wallez dijo:
 

Carsten Ziegeler wrote:
   

Sylvain Wallez wrote:
     

Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session
are now unrestricted.
The only difference with the real objects is that a special wrapper
is used for request, response and context that shows their respective
attributes are JS properties (not sure I personally like it, but
that's how they have been since the beginning).
This closes a lot of open bugs ;-)
       

Great! Why do we need this special wrapper?
     

Because removing it means a backwards incompatible change!
It adds small syntactic sugar by allowing you to write
'cocoon.session.blah' instead of 'cocoon.session.getAttribute("blah")'
and the same on request and context.
I personally didn't knew about it until today and therefore never used
it...
   

I thought in the form flow samples is. The construction is often used to
test request params. ;-)
ie: cocoon.request.myButton
 

Oh f*ck, that's even worse than I thought. It now returns the request 
*attributes* because I was fooled by the implementation of FOM_Request 
which was buggy: getIds() which lists the object's properties was 
considering *attribute* names just as FOM_Session and FOM_Context, but 
get() which actually gets a property was considering *parameter* names.

What that means is that (before today's change):
- cocoon.context.blah == cocoon.context.getAttribute("blah")
- cocoon.session.blah == cocoon.session.getAttribute("blah")
- cocoon.request.blah == cocoon.request.getParameter("blah") and not 
cocoon.request.getAttribute("blah").

This is clearly inconsistent.
Furthermore, I really don't like this naming scope filled from different 
sources (the object itself and some other data), especially when one of 
the sources comes from the browser.

And what about conflicts? Fortunately the object is searched before 
request parameters, otherwise this would be a nice security hole.

So, what do we do? Do we keep this inconsistent behaviour, deprecate it, 
remove it now?

WDYT?
Sylvain