cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
Date Tue, 27 Apr 2004 08:39:46 GMT
On 27.04.2004 10:19, Bruno Dumon wrote:

>>>...At the time where we discussed this, I proposed 
>>>active/disabled/hidden, which is more traditional for GUI widgets:
>>>- active is the normal behaviour (what we have today)
>>>- disabled is like @type=output with the additional behaviour that the 
>>>request parameter isn't considered (avoids hacking using forged 
>>>requests)
>>>- hidden means that the widget doesn't output its SAX fragment, 
>>>effectively hiding the value along with ignoring the request parameter 
>>>as in disabled state....
>>
>>Sorry to jump in suddenly, just my two cents on the terminology: I 
>>think "editable / readonly / hidden" would express these widget states 
>>more clearly.
>>But I don't want to interfere if you guys have been discussing this 
>>already ;-)
> 
> Don't remember if it's already discussed. The names you suggest make 
> sense for e.g. a field widget, but would then sound strange when applied
> to eg a repeater widget (an "editable" repeater?).

I also thought of readonly first, but it makes indeed no sense for the 
most widgets. I had a look at the XUL elements 
(http://xulplanet.mozdev.org/references/elemref/) and they all have an 
@disabled (checkbox, menu, radio, textbox, etc.). Textbox provides 
additionally @readonly, menulist @editable.

I agree to Bruno's proposal: enabled (= default behaviour), disabled, 
hidden.

Joerg

Mime
View raw message