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 [EMAIL PROTECTED] [EMAIL PROTECTED]
