Antonio Gallardo wrote:
On Mie, 9 de Febrero de 2005, 12:06, Sylvain Wallez dijo:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Great! Why do we need this special wrapper?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 ;-)
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
