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