cocoon-dev mailing list archives

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

> Upayavira wrote:
>> Sylvain Wallez wrote:
>>> Claudius Spellmann wrote:
>>>> Hi,
>>>> I've created a patch to set a visibilitystatus for widgets. This 
>>>> means that all widgets can be set visible or invisible on a form 
>>>> when a form is created or using flowscript.
>>> This has already been discussed here: we need widget states. 
>>> However, state isn't limited to visible/invisible. We also need 
>>> states like active/inactive.
>>> AFAIR, the list of states we came up to was:
>>> - active : the current behaviour
>>> - disabled: the widget is displayed, but its value (or sub-widgets 
>>> in the case of containers) isn't read from the request.
>>> - hidden: the widget isn't displayed, and of course it's value isn't 
>>> read from the request.
>>> States should be inherited by child widgets, taking into account the 
>>> following state priority:
>>>  active < disabled < hidden.
>>> That means that if a repeater is hidden, its children will be hidden 
>>> also even if their own state is active or disabled.
>>> We also need to be able to set an intial state in the form 
>>> definition (default being "active"). I propose a common "state" 
>>> attribute for this, available on all widget types, e.g.
>>> <fd:repeater id="foo" state="hidden">
>>>  ...
>>> </fd:repeater>
>>> We've discussed this many times and it appears it is a real need 
>>> now, so let's do it right now.
>>> Are we ok with this definition?
>> How does this relate to validation? The reason I ask is that this 
>> feels very close to support for wizards (unless I'm just being stupid).
>> If we can 'group' a few widgets together, and enable or disable them, 
>> we could then show part (a) of the form, then part (b), etc. Now, if 
>> a field in this contect is 'disabled', a value will not be read from 
>> the request, and no validation would be done on its value.
>> Thoughts? Am I off beam?
> No, but you add another concern to the picture :-)
> 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  ????

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.

Just some ideas

View raw message