Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <420A6B65.6090106@apache.org>
Date: Wed, 09 Feb 2005 20:58:29 +0100
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
References: <40CD7782.1070009@apache.org> <420A26B6.3020809@apache.org>
    <420A4ABA.4080601@apache.org> <420A511A.1030501@apache.org>
 <34258.10.0.0.5.1107972825.squirrel@www.agssa.net>
In-Reply-To: <34258.10.0.0.5.1107972825.squirrel@www.agssa.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }