cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)
Date Thu, 01 Apr 2004 09:45:03 GMT

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 

> 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.

see above,

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message