Tim Larson wrote:
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.
I felt that, and I'm sorry for not coimming back to this topic earlier, I really think these added widgets will greatly enhance the cforms feature-set
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.
ok, I rest my case, reading up your argumentation it does sound like the 'value' is enough... but in the ifelseif style we'll need some indication of value-setting then?
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).
up to now this has been under the (implied) control of the widget type (code in the class) itself, (e.g. fd:output versus fd:field)
and I like this more then the explicit attribute which might not make any sense?
for the choice I think it could easily detect c-switch or ifelsif style and thus decide what to with values that were set, no?
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.
WDYT?
see above,
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
