cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
Date Tue, 27 Apr 2004 08:31:01 GMT
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"/>? 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.


View raw message