Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41540AB9.4020201@juwimm.com>
Date: Fri, 24 Sep 2004 13:53:29 +0200
From: Claudius Spellmann <claudius.spellmann@juwimm.com>
User-Agent: Thunderbird 0.6 (Windows/20040502)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Widget states: let's do it (was Re: CForms making widgets   
   invisible)
References: 
 <1E0CC447E59C974CA5C7160D2A2854EC02FECED1@SJMEMXMB04.stjude.sjcrh.local>
 <32874.80.219.13.29.1095969731.squirrel@80.219.13.29>
 <4153E3EE.7000404@apache.org>
In-Reply-To: <4153E3EE.7000404@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sylvain Wallez schrieb:

> Antonio Gallardo wrote:
>
>> Hunsberger, Peter dijo:
>>  
>>
>>> Sylvain Wallez <sylvain@apache.org> writes:
>>>   
>>>
>>>> Yes, that a problem we already have to face today if e.g. a required
>>>> widget is not present in the form template.
>>>>     
>>>
>>
>> I think this is an application bug an we cannot take care of that in the
>> definition. ;-) See below....
>>
>>  
>>
>>>> Some ideas about this problem?
>>>>     
>>>
>>> Yes; why would you ever do validation on a field that the user cannot
>>> change?
>>>
>>> If a field is hidden but not included on the form the user cannot
>>> (normally) change it.  If there is some JavaScript that updates it, it
>>> is up to the developer to make sure that only valid values come back.
>>> (Hand crafted POSTS are not something that can be solved by validation
>>> so forget about them for the moment.)  IOW, the only time you do
>>> validation is if the values that can be returned by the widget can be
>>> entered by the end user.
>>>
>>> A side comment is that much of this sounds like a mixing of concerns.
>>> Presentation and validation should pretty much be separated, use two
>>> different flags if you want to allow for turning validation off and on
>>> and don't mix it with the presentation state.
>>>
>>>     formInclusion = normal | disabled | hidden | notIncluded
>>>     validation = true | false
>>> Where validation defaults to false if formInclusion is not normal. (And
>>> here I use hidden because it means exactly what you would expect as a
>>> normal HTML author...)
>>>   
>>
>>
>> I like this new attributes. Another thing to be done is discuss where we
>> will include this (I expect optionals atrributes - to not break
>> compatibility):
>>
>> fd,ft,fi
>>
>> I also think we can find a better names:
>>
>> formInclusion --> show, render, presentation, view, [fill a new name]
>> notIncluded -->  Excluded
>> validation --> validate
>>  
>>
>
> Ok, maybe the "phantom" state isn't a good idea after all. But I still 
> consider that "hidden" is a view concern since it has no impact on the 
> request processing.
>
> Now I have a problem with separating state and validation: what does 
> it mean if an active widget has validate="false". Does it mean that we 
> allow the user to validate a form where she has input invalid data? 
> Doesn't seem good to me...
>
> Sylvain
>
I don't think that having a separate validation state is a good idea, I 
also think that all widgets should be validated when data is entered or 
changed. By doing this no phantom state would be necessary because 
nobody can enter data into an invisible field and when no data is 
entered nothing would be there to be validated, so an invisible state 
would be sufficient.
Using that apprioach the main problem in my opinion is the "required" 
flag. What would happen if a required widget is invisible an no data is 
entered ? (There certainly wouldn't be any validation going on when no 
data was prevoisly entered) I guess there has to be a distinction 
between validation and checking wether a widget is required or not.

By the way why do we need better names I think when using active, 
disabled, invisible for widget states it is pretty clear what's meant, 
but I guess thats just another personal opinion.
The main thing is that whatever the state is called it should be pretty 
self-explanatory or endusers will get confused.

Claudius