cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Revisiting Woody's form definition
Date Thu, 31 Jul 2003 10:17:58 GMT
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 
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.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message