cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Date Wed, 09 Feb 2005 20:42:53 GMT
On Mie, 9 de Febrero de 2005, 13:58, Sylvain Wallez dijo:
> 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.

It was "carefully" designed. ;-)

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

Hmm... the problems is that "cocoon.request.blah" was released and maybe
is used is used (by us and other people?) in a lot of places and maybe
other peopl! :-(

I think the best is to keep the 2.1.x "as is" and perhas deprecate it in
the next (2.1.7) release and remove it in 2.2.
...

[Antonio while typing, pausing to answer customer's questions by phone saw
that Sylvain already fixed the problem. Antonio is very happy and wants to
test the last change.]

...

Anyway, you are faster than me! I already saw the last patch. I will check
if it is working now as expected. Mr. Incredible, thanks for you time! ;-)

Best Regards,

Antonio Gallardo


Mime
View raw message