Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <33825.10.0.0.5.1109465101.squirrel@www.agssa.net>
In-Reply-To: <4220F98F.6020308@verizon.net>
References: <4220F98F.6020308@verizon.net>
Date: Sat, 26 Feb 2005 18:45:01 -0600 (CST)
Subject: Re: JS versus Java [was Re:  FOM inconsistency (was Re:
     [VOTE]Unrestricting the FOM)]
From: "Antonio Gallardo" <agallardo@agssa.net>
To: dev@cocoon.apache.org
User-Agent: SquirrelMail/1.4.3a-6.FC2
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

Chris:

The name JavaScript was just a good marketing meme and the reason why
Netscape choosed this name for this language called Javascript.

I agree with you. Recently I found a lot of changes to java-zation of the
JS Flow code. I see too much verbosity in the "new" changes. The reason to
not like them. I prefer to have less code to write. If Javascript allow me
it. I am happy using the real Javascript features. ;-)

Best Regards,

Antonio Gallardo

On Sab, 26 de Febrero de 2005, 16:34, Christopher Oliver dijo:
> 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
>>
>