cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Widget states again (was Re: fi:booleanfield[fi:styling/@type='output'])
Date Tue, 27 Apr 2004 06:30:16 GMT
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)
- 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.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message