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 Wed, 30 Jul 2003 15:44:24 GMT
Marc Portier wrote:

> Sylvain Wallez wrote:
>
>> Marc Portier wrote:
>>
>>> Sylvain Wallez wrote:
>>
>>
>> <snip/>
>>
>>>> Validators currently exist only for datatypes, and not yet for 
>>>> bindings (this is on my todo list).
>>>
>>>
>>> yep, some nuance though:
>>>
>>> there should be only one validation cycle!
>>> what I mean is:
>>>
>>> - we probably do want to be able to express validation-rules by 
>>> using some of the syntax we currently find in the binding file, that 
>>> is based on the business-object models we want to manipulate
>>>
>>> - however: I don't see a reason for specific validation that only 
>>> kicks in when doing the save-binding (i.e. typically at the end of 
>>> the use case) since that would defy the whole idea of having a 
>>> woody-form-model that can validate *early* some user-input?
>>
>>
>> When the form is bound to application data, datatype validation isn't 
>> enough and there *must* be some application data-related validation 
>> before saving.
>
>
> no and yes :-)
> I mean yes, but we use 'datatype-validation' to depict different 
> things (we are surely saying the same thing here AFAICS)
>
>> Let's take the simple use case of user registration :
>> - datatype-level validation : name is not longer than 20 characters 
>> (--> "please use a shorter name")
>> - application data-level validation : name doesn't already exist in 
>> the database (--> "this name is already used. Please choose another 
>> one").
>>
>> Note that the second validation, although binding-specific, can be 
>> performed early and doesn't need to be delayed until the save-binding.
>
>
> 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 !

> 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 ?

> 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).

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.

> and I have the feeling you share that vision 


Totally. What we're discussing here are only low-level architectural 
details, even if important.

>>> having said that I still think the validators are tied to datatypes, 
>>> only some of those datatypes are to be retrieved or introspected 
>>> from the business domain directly (and can be expressed as such, 
>>> including business specific validation) 
>>
>>
>> I the above example, the second validation cannot be defined on the 
>> datatype, since it must be checked only when a *new* user is created 
>> and not everywhere a user name is input. It's therefore specific to 
>> the registration form.
>
>
> yep, see above for the nuance of havig more then one registration form 
> that all need this
>
>>> or am I missing something?
>>> (maybe all of this is introduced by 'binding' being a bad name for 
>>> what it currently is: it really just is run-time data-mapping, not 
>>> design-time typing) 
>>
>>
>> Uh ? What do you mean by "design-time" and "run-time" ?
>
>
> forget about that: more bad naming to make up for the other bad naming 
> :-(
>
> 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/.

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 ?

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