cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] Revisiting Woody's form definition
Date Wed, 30 Jul 2003 15:09:31 GMT
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)

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

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

and I have the feeling you share that vision

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

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?

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message