On Tue, 2004-04-27 at 10:31, Joerg Heinicke wrote: > On 27.04.2004 08:30, Sylvain Wallez wrote: > > >> 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. > > I did not want to propose direction="save|load|both" for the definition, > it was just the comparison to the current syntax in the binding. > > > 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. > > Password fields :) > > > 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. > > Do you mean no SAX fragment at all, i.e. not even <input > type="hidden"/>?
Yes, I'd interpret it that way. hidden = disabled + invisible > Of course we preserve the state server side, i.e. the > value round trip through the form like before-cforms-times is not > needed, but some scripts might need the value. the value of disabled/hidden widgets shouldn't be changeable by processing a client request. It is true that such widgets are less useful in stateless scenario's, but that's the case with the output widget today already. If you want the state to come back from the request, use an enabled widget but with an appropriate styling option to hide it. This makes me think: enabled/disabled has nothing to do with visible/invisible. The last one sounds much more like a styling concern. Do we need the hidden widget state at all? -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
