cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Dynamically changing labels, was Re: Woody + FlowScript : documentation on model
Date Wed, 28 Apr 2004 15:57:06 GMT

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


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


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

View raw message