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: <41891AC6.1010609@apache.org>
Date: Wed, 03 Nov 2004 18:52:06 +0100
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: CForms: widget states added
References: <5E091A68F794974CAF431CA31F5AF2CC1894F6@server.bizzdesign.nl>
 <41889188.4060805@apache.org> <4188B213.90505@gmx.de>
 <4188B838.8000702@apache.org> <4188C7D0.3050306@gmx.de>
In-Reply-To: <4188C7D0.3050306@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Joerg Heinicke wrote:

> On 03.11.2004 11:51, Sylvain Wallez wrote:
>
>>>>> Does it fix this one?
>>>>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27598
>>>>
>>>>
>>>> Mmmh... not sure, although you can prevent a widget from reading 
>>>> its value from the request by setting it's state do "disabled". 
>>>> This bug is more likely to be fixed by having widgets only changing 
>>>> their values *if* the corresponding request parameter is present, 
>>>> as proposed by Tim in the "[lazy vote] cforms request processing 
>>>> thread".
>>>
>>>
>>> I don't think so. The bug was about an analogy to @direction="load" 
>>> in binding. Having a widget with output styling does not prevent it 
>>> from reading from request though there will not be request parameter 
>>> of it.
>>
>>
>> That's exactly what the request processing thread is all about: don't 
>> change a widget's value if the corresponding request parameter 
>> doesn't exist. That's exactly the case of output styling.
>
>
> When re-reading my written comment above I see I was not clear enough. 
> It must read:
>
> Having a widget with output styling does not prevent it from reading 
> from request though there will not be request parameter of it by 
> default. This means you can hack the URL to change the value but you 
> should not be able to change the value of the widget at all as it is 
> set to 'do not read the value from request' (the analogy to binding's 
> @direction='load').


Ah, ok. So then instead of using type="output", the widget's state 
should be set to "disabled". That way, the value will never be read.

>>> So I'm about to close the bug if the widget states work - what I 
>>> assume ;-)
>>
>>
>> I would wait for this do-not-reset-value-if-parameter-is-not-present 
>> thing to be implemented.
>
>
> Also after my clarification?


I leave this to your judgment ;-)

Sylvain

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