[on changing the label on the instance-level]
Bruno Dumon and Sylvain Wallez wrote their parts of:
Well if people need it we better make it possible. After all, it's possible to change e.g. the selection list, so why shouldn't it be possible to change (or rather "override") the label?
Selection-list is used at the application level, whereas storing the label in the definition is mostly a convenience (it's part of the display data). Next, we will be asked to dynamically change the hint, help, accesskey, etc.
IMO, this is going too far. If some people need changing labels, the simplest way to do it is at the view level, i.e. in the template, possibly relying on data passed from the flowscript, but out of the form's responsibility.
I need to think more about this, but I agree with the basic point that label and other display data is a concern of the display pipeline, and that it should be handled over there. OTOH it could then also be said that it should not be part of the form model at all. I know it's because of convenience, but being able to modify the label (or styling information for that matter) from within the flowscript could also be called convenience :-)
If people start using output widgets to dynamically set the label, then that's also far from optimal.
indeed!
Anyhow, I'd need to understand better the usecases for doing such things to think about the best approach.
I have another one to add onto your list of convenience :-)
<fi:value> why don't we allow it on the field-definition and templates?
it could serve as a hint-default value that gets inserted into the publication line (only if the widget.getValue()== null), but never actually sets the widget value without a confirming request from the user. (this is better then setting defaults in binding since then save() would copy over to the backend while 'null' might be more appropriate)
the convenience would be to be able to add it on both definition or template levels and apply some logical fall-back rules in taking which one: 1/ widget's own getValue() 2/ whatever was in the template 3/ then use what was in the defintion
and IMO the same could indeed apply for hint/help/label
as such, it is not IMO part of the 'displayData' (I know the method calls it like that) but more part of the 'instance-data' (as the fi: namespace we agreed upon for those is hinting)
IMO everything in the fi namespace deserves to be (changeable) on the instance level
(this seems to be a case of valuing the namespace separation higher then the split and naming provided by the current code-implementation)
wdyt?
-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]
