Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])

[Bruno Dumon <br...@outerthought.org>]

On Tue, 2004-04-27 at 08:30, Sylvain Wallez wrote:
> Joerg Heinicke wrote:
> 
> > On 26.04.2004 23:43, Sylvain Wallez wrote:
> >
> >>> They would also be reset after request.
> >>>
> >>> These stylings make only sense if the form widget values are not 
> >>> evaluated. I can imagine a confirmation page, where just the submit 
> >>> widget (ok vs. cancel) is evaluated.
> >>
> >>
> >> BooleanField is special as "no parameter" means "false", but for 
> >> regular Fields, what do you think about not resetting the value to 
> >> null if the request parameter is not present? This would make 
> >> @type="output" more useful than it is today.
> >
> >
> > I would like to see a more explicite setting for this behaviour - and 
> > also supporting all widget types. We already talked a bit about a 
> > direction="save|load|both" for the field definition in relation to 
> > reading the values from request. This would replace fd:output and 
> > styling="output" with the above mentioned consequences.
> 
> 
> Having this handled by a widget state rather than a particular styling 
> sounds better. But although save/load/both makes sense for the binding, 
> it doesn't IMO fit for widgets. What's the meaning of a widget in 
> "save-only" mode? A widget that can be given a value by the user but 
> which is never output by the application? It doesn't make sense.
> 
> 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)

maybe "enabled" is better as name, opposite of disabled?

> - 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.
> 
> This kind of feature is a must-have for complex workflows or 
> authorization schemes as it allows a single form and template to be 
> easily adjusted to the authorized visibility and modification, depending 
> on the application context.

So I presume the goal is to make this adjustable on the instance-level.

I see no problem when doing this as a one-time configuration after
creation of the form. I imagine people will however be changing this
dynamically also, i.e. between form submits. This might then give
troubles (or unexpected results) if a user goes back and submits an old
form, i.e. one in which a few widgets were disabled, to a form instance
where now those widgets are enabled. I see this mostly as a problem the
application developer should handle.

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