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
