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 00:29:58 GMT

Sylvain Wallez wrote:
> Marc Portier wrote:
>> Sylvain Wallez wrote:

<snip />

>> agree totally: that is the crux!
>> (maybe we should change the binding word: this validation is 
>> business-model specific)
>> the main thing to note is that this specific validation will also be 
>> executed during the form.process()
>> as such I looked at it as being the inline extra specification of an 
>> existing datatype (creating thus an anonymous inline datatype as we 
>> named it earlier) 
> Ah, I understand ! Clever idea !

thx chap, I just extended your idea (I try to pick them up fast ;-))

>> in the same way this emerging 'business-specific datatype' could 
>> probably just be added into the datatype-catalogue I presume (for 
>> cross app consistency if that would make sense: e.g. suppose different 
>> forms for registration based on a possible of 
>> regular-gold-platinum-speaker case that map to the same uniqueness-id 
>> rule!)
> Yep. This would mean a "new-user" datatype extending "user" with the 
> additional validation, right ?


>> maybe this is explains why I added business-domain specific validation 
>> to be adding onto the datatype (and not be distinct from it)
>> but basically I just wanted to make the remark that it has nothing to 
>> do with the actual binding.saveFormToModel() action 
> Yes, you're right. But this may have to do with the object passed to 
> this method (i.e. the application data).

ah, you say that you would need the actual business-object to 
perform the validation?

blast, I feel so stupid to have overlooked that fact (guess I 
didn't recognise this yet in any of the presented examples)

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

<snip />

>> basically I'm getting the feeling some of the discussions are mixing 
>> up what happens at different moments:
>> 1/ while doing calls to form-manager and bind-manager (to be called 
>> typing? defining? setup?)
>> 2/ while calling the form.process (datatype conversion, validation and 
>> eventhandling)
>> 3/ while calling the binding.load/save (data mapping/copying)
>> back to this discussion:
>> recognising the 'business-domain-validation' stuff is IMO something 
>> that happens at 1/ by the form-manager even if it might be expressed 
>> in terms of syntax we know from the current binding definition but it 
>> has nothing to do with 'binding'
>> - not with the activity in 3/
>> - and probably even not with the binding-manager
>> more clear? 
> Yes. I was fooled on the wrong track because binding was the only place 
> where application data was available.
> But I don't agree business-domain-validation should happen in 1/ since 
> it needs the form values parsed in 2/.

sure, my mistake
what I meant was that understanding (recognising) 'what to do' as 
extra validation happens in stage 1/ (typing)

but you are right: performing the actual validation, i.e. 'doing 
it', is surely happening during 2/ (datatype conversion, 
validation and eventhandling)

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

> Sylvain

-marc= (looking forward to your conclusions / proposal - wiki page)
Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message