cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
Date Tue, 27 Apr 2004 09:57:22 GMT
On Tue, 2004-04-27 at 11:44, Bertrand Delacretaz wrote:
> Le 27 avr. 04, à 10:19, Bruno Dumon a écrit :
> 
> > On Tue, 2004-04-27 at 08:37, Bertrand Delacretaz wrote:
> >> Le 27 avr. 04, à 08:30, Sylvain Wallez a écrit :
> >>> ...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?).
> 
> Why not? If a repeater is a container for things, an "editable 
> repeater" could be a container for "editable things" (IMHO).

You could look at it that way, but I like enabled/disabled better
(IMHO).

Or if we'd drop the hidden state, we could simply have
enabled="true/false".

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message