cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Date Thu, 23 Sep 2004 09:05:32 GMT
Claudius Spellmann wrote:

> Sylvain Wallez schrieb:
>> Claudius Spellmann wrote:
>>> Sylvain Wallez schrieb:
>> <snip/>
>>>> Mmmh... we could say that validation is not performed on 
>>>> disabled/invisible widgets and their children. But this may cause 
>>>> some forms to appear falsely valid, as non-enabled widgets may be 
>>>> required and/or have validators that use values of other widgets.
>>>> So I would better go the safer way, which is to validate *all* 
>>>> widgets.
>>>> As for wizards, we could have an additional method on the JS Form 
>>>> object that, instead of handling the whole form at once, may handle 
>>>> it's first-level children which may be widget groups for each page 
>>>> of the wizard.
>>>> Sylvain
>>> Ok if a widget is set invisible it is not rendered by cocoon but 
>>> that doesn't mean that the widget is not existing in the widget 
>>> container so if a widget is required and not visible but still 
>>> exists in the container does mean it could be validated  ????
>> Yes.
>>> What about following widget states: enabled (default) < disabled < 
>>> hidden < invisible
>>> The difference between hidden and invisible would be that hidden is 
>>> still rendered but with an hidden attribute in the declaration and 
>>> would go through the validation process. Invisible on the other side 
>>> could be taken of the form completly and while a widget is in an 
>>> invisible state all validation would be switched off. This way every 
>>> user could decide wether they want to use validation or not and the 
>>> output still  would look the same.
>> Interesting thoughts. But as we saw previously, "hidden" has an 
>> implied meaning because of its use for <input type="hidden"> in HTML 
>> and I'd like to avoid it.
>> What you're describing here is a widget state that is even less 
>> visible than invisible, since no validation occurs. What about a 
>> "phantom" state, where the widget exists but isn't validated?
>> BTW, overnight I finally felt that "enabled" being the negation of 
>> "disabled" can lead to confusion as when we have to talk about a 
>> widget that's not in "enable" state, the natural word that comes is 
>> "disabled" which is only one of the particular possible states for a 
>> non-enabled widget. So in the end, I think "active" is better than 
>> "enabled".
>> That would lead to:
>>  active (default) < disabled < invisible < phantom
>> Thoughts?
>> Sylvain
> Ok sounds good to me
> What would happen when an invisible field doesn't pass validation and 
> the enduser of a running system doesn't know that he's made a mistake 
> entering data.
> The point I'm trying to make is that informing endusers about 
> validation errors could be a tricky issue becausae a user can't enter 
> data into fields he cannot see and would be a burden for system 
> developers because they have to test forms throughly to avoid confusion

Yes, that a problem we already have to face today if e.g. a required 
widget is not present in the form template.

Some ideas about this problem?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message