Sylvain Wallez schrieb:
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 ????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
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 Claudius
