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 Wed, 22 Sep 2004 15:53:40 GMT
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.


>> Are we ok with this definition?
> Mostly.

And now, with "enabled"/"disabled"/"invisible"?



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

View raw message