cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] Revisiting Woody's form definition
Date Thu, 31 Jul 2003 10:11:31 GMT

Sylvain Wallez wrote:
> Marc Portier wrote:
> <snip/>
>>> I see two solutions for this :
>>> - the messy one (IMO) : add some non-visual fields in the form to 
>>> hold the necessary data,
>>> - add a get/setApplicationData() on FormContext so that widgets can 
>>> use it during form.process() if the form has an associated binding.
>> surely I prefer the second.
>> and guess what my mantra-remark is: "it isn't really tied to binding" :-)
>> what I mean is that business-specific-validation that requires the 
>> ApplicationData present could be driven completely from the flow 
>> (without it making use of the declarative data-mapping offered by the 
>> current binding)
>> in fact we might consider naming this the ValidationContextBean rather 
>> then ApplicationData? 
> Agree. There's a great probability that ValidationData (why should it be 
> a bean?) will often be the same as ApplicationData, but it formally 
> doesn't need to. Moreover, there are certainly many uses cases where 
> ValidationData is required but the form has no binding.

+1 on dropping -Bean suffix (everything in Java is a bean if you 
want it to. I was thinking about validation rules based on jxpath 
expressions of course ;-))

-0 on leaving -Context in favor of -Data:

I agree that most of the time it will be a quite passive object 
providing information elements where the custom validation-rules 
can hook into...
However I wouldn't mind if this ValidationContext can be called 
by these custom validation-rules to do some active stuff. This 
might very well make the design of these custom thingys a bit easier

So I'ld like the name to be more neutral regarding its 
passive/active position, this makes -Context a better candidate 
then -Data IMHO, but I'm open to suggestions...

> <snip/>
>>> Actually, if application data is added to FormContext, it can be 
>>> propagated in the ValidationRule's ExpressionContext (e.g. as an 
>>> "_applicationData_" variable). There will be then no difference 
>>> between a form-only-validation and a business-domain-validation. We 
>>> just have ValidationRules that use the application data variable and 
>>> others that don't.
>>> What do you think ?
>> I think it makes perfect sense, and even more important it shows we're 
>> on the same track here (also enthousiasm-wise :-)) 
> ;-)
>> -marc= (looking forward to your conclusions / proposal - wiki page) 
> That's today's todo, but these important and stimulating discussions eat 
> up all most of my time. But we're near to the convergence point !

yep, we're getting there:

it is reflected by the ratio of the 'yep' word over the others
(thank god the 'yep' word is payed accordingly ;-) )

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

View raw message