cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)
Date Wed, 31 Mar 2004 22:07:36 GMT
Marc wrote my comments very well in my place, so I will move on to
some new comments. By the way, thank you both for jumping in to
this discussion. I have been holding back on implementing any of
the ideas in the WoodyScratchpad until there would be a discussion
like this and the forming of a consensus.

We must be able to detect when a choice widgets changes cases, so
we need to remember the previous case so we can compare against it.
We also must know what the current selected case is to be able to
drive the template and the save side of the binding.

We do not need to be able to directly set a case, except via setting
the values that are references by the expression(s) in the "expr"
attribute of the choice or in the "test" attributes of the case's.

On the other hand, since the choice has to store a value indicating
which case is selected, we could just go ahead and treat this as the
"value" of the choice widget.  Getting the value will tell you the
current case, and attempting to set the value will trigger the
evaluation of the expression in the "expr" attribute, eventually
causing a case to be selected and the underlying value to be set.

As you can see, externally setting the value is only useful for the
"c switch" style of the choice widget, unless you used the attempt
to set a value on the if-elseif-elseif-else style choice widget as
a manual trigger to cause re-evaluation and just discarded the
specific value that was passed.

I think it would be handy to be able to specify for all/most types
of widgets a direction attribute like we have in the binding: load,
save, or both. We may choose different names like input, output,
both, none, etc.

This would control whether the request parameter for a widget would
be processed (e.g. so the widget will not be reset to null when the
parameter is missing, and to prevent the user setting the value by
manipulating the posted parameter values), and whether the current
value of a widget would be made available to the template layer
(e.g. we do not want to send passwords back to the user).

I bring this up in part because these options should give us the
needed protection against the user hacking the case selection of
most choice widgets, while still allowing selected choice widgets
to easily allow the user to select the case.


--Tim Larson

View raw message