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 11:14:53 GMT


Sylvain Wallez wrote:
> Marc Portier wrote:
> 
>> Sylvain Wallez wrote:
>>
>>> Marc Portier wrote:
>>>
>>> <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.
>>>
>>
>> yep,
>> +1 on dropping -Bean suffix (everything in Java is a bean if you want 
>> it to. I was thinking about validation rules based on jxpath 
>> expressions of course ;-))
>>
>> -0 on leaving -Context in favor of -Data:
>>
>>
>> I agree that most of the time it will be a quite passive object 
>> providing information elements where the custom validation-rules can 
>> hook into...
>> However I wouldn't mind if this ValidationContext can be called by 
>> these custom validation-rules to do some active stuff. This might very 
>> well make the design of these custom thingys a bit easier
>>
>> So I'ld like the name to be more neutral regarding its passive/active 
>> position, this makes -Context a better candidate then -Data IMHO, but 
>> I'm open to suggestions... 
> 
> 
> 
> Mmmh... by "active" I guess you mean it provides not only data, but also 
> methods ? Then you're right. But this "active" word must be banned to 

yep

> name this object as it should have *no* impact on the system state. It's 
> the same difference that exists between sitemap matchers and actions : 
> method-wise, they look similar, but only actions can have side effects.
> 

yep again

I find -Context only slightly less passive then -Data but just a 
touch more neutral in this respect

(e.g. ValidationHandler or even ValidationProvider would have 
been overdoing it)

> Sylvain
> 

regards,
-marc=
-- 
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