Andreas Hochsteger wrote:
Hi!
I have to tell you that this thread is really a pleasure.
It's really amazing what 'shared neurons' (like Marc called it) are possible to do ;-)
I often have the feeling that while reading a message some ideas come to my mind and recognize that in the next post they are already covered.
Perhaps many do like me to just sit back and enjoy watching ideas evolving to genious concepts. - No need to step in ;-)
But don't saying anything and just watching might not be that good, so all I can contribute now are these pushing words.
So keep up that good work to all people involved here!
thx mate,
finding shared neurons over at Sylvain's brain is already great fun, but statements like yours above give back tremendous Energy
don't feel shy to step in and ride the wave if you feel like it... after all, I'ld like to return the favour :-)
-marc=
Bye, Andreas
Marc Portier wrote:
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 ?
absa
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 http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
