cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [RT] Revisiting Woody's form definition
Date Thu, 31 Jul 2003 09:12:53 GMT


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/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message