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. WDYT? --Tim Larson
