cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
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 

What do you think ?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message