<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.
<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 !
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
