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
