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 }