Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Claudius Spellmann wrote:
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.
So, we will have two different types of hidden? One is normal html type="hidden", which *reads* from request, and another is form's hidden, which does not?
They address different concerns: the <input type="hidden"> is a styling concern, as the value has to be read from the request by the widget, whereas the hidden state is an application concern which forbids access to the widget by the client.
Maybe "invisible" as proposed by Claudius is better, as you can find something that's "hidden" by searching around (i.e. looking at the page source) whereas you can't find an invisible thing.
This "invisible" state led me to look back to AWT Component which has setEnabled(boolean) and setVisible(boolean). IMO we should have only one tri-state property because "invisible" is an increased constraint on the enable status.
So finally, my proposal is "enabled" (default), "disabled", "invisible".
We also have the case of password fields [1] that should read a value but not output it, but IMO this is a very special case that should be handled by a special widget class.
<snip/>
Are we ok with this definition?
Mostly.
And now, with "enabled"/"disabled"/"invisible"?
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108305466005202&w=2
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
