Return-Path: Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 59915 invoked by uid 500); 31 Jul 2003 00:29:53 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 59902 invoked from network); 31 Jul 2003 00:29:52 -0000 Received: from smtp1.xs4all.be (195.144.64.135) by daedalus.apache.org with SMTP; 31 Jul 2003 00:29:52 -0000 Received: from outerthought.org (195-144-088-041.dyn.adsl.xs4all.be [195.144.88.41]) by smtp1.xs4all.be (8.12.9/8.12.9) with ESMTP id h6V0Txqr005522 for ; Thu, 31 Jul 2003 02:29:59 +0200 Message-ID: <3F286306.2050903@outerthought.org> Date: Thu, 31 Jul 2003 02:29:58 +0200 From: Marc Portier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en, nl-be MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] Revisiting Woody's form definition References: <3F2797FF.2020809@anyware-tech.com> <3F27BF47.4080103@outerthought.org> <3F27CF70.6060701@anyware-tech.com> <3F27DFAB.2030706@outerthought.org> <3F27E7D8.9070902@anyware-tech.com> In-Reply-To: <3F27E7D8.9070902@anyware-tech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Sylvain Wallez wrote: > Marc Portier wrote: >> Sylvain Wallez wrote: >> >> >> 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? >> 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/ mpo@outerthought.org mpo@apache.org