cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
Date Sat, 26 Feb 2005 22:34:55 GMT
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 
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,


>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
>>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 
>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?

View raw message