[Springframework-developer] RE: validation stuff

[Keith D. <kd...@cs...>]

I think we're nearing agreement.  Your 'AttributesValidator' is =
analagous to
my 'ValidatorRegistry', except your class has the capability to kick off
validation for any command/bean, which is a great idea.

This is what I'm proposing:

1. The user creates source-level-metadata describing property validation
rules for their various bean classes.

2. Using the spring metadata API, the system auto-generates
BeanValidator/PropertyValidator instances (the API we've been discussing
with the good abstractions) for each validateable class.  So you know =
for
each bean which properties are to be validated, and which validation =
rules
apply (and there is nice model for this.)

	Note: this step could require some Spring configuration to specify
which validateable classes to introspect using the metadata API (or we =
could
do it like you do it, which is lazily introspect every command...either =
way
works for me...one is more explicit, the other is more flexible.)

3. Once the BeanValidator models are created, individual BeanValidators =
are
added to the ValidatorRegistry (we might need a better name than
'registry'.) (again this may happen in reverse if we go with on-demand
'validation-rule discovery' like you do now.)

4. The ValidatorRegistry is bound to each controller needing to validate
commands.  It provides a one stop shop for validating any bean.

5. Each controller simply calls 'registry.validate(command, results)', =
and
it kicks the validation process off, returning localized results =
messages.
The algorithm will proceed down through any object graph and validate =
nested
beans (this opens up some issues: what if a nested bean property is =
null?)
I can improve performance on this by having separate BeanValidators
generated for each bean class, and then link them for the algorithm to
traverse...)  I can create a Errors adapter for the
ValidationResultsCollector interface, since Errors is supported with jsp
tags for rendering, right?

Is that acceptable? Did I miss anything? =20

Do you prefer 'explicit' (beforehand) configuration of the validateable
classes via the metadata API or do you think it is better for that to =
happen
lazily/implicity when the registry validate(command, results) method is
invoked?  In the latter case, we would cache the
BeanValidator/PropertyValidator references in the registry once we =
derive
them from the source-metadata resulting in better performance.

Keith



-----Original Message-----
From: Seth Ladd [mailto:se...@eh...]=20
Sent: Wednesday, March 03, 2004 6:30 PM
To: Keith Donald; spr...@li...
Subject: Re: validation stuff


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(putting this reply on list because of some explanation that might =
others)

Keith Donald wrote:
| Seth,
|
| The way I look at it is this:
|
| The validation rules I want to apply to a domain object are generally=20
| very specific to that domain object.  For example, I may have a Pet=20
| class, like in the Pet clinic.  I want to validate that all Pet's have =

| a name, all
Pet's
| have a unique name, and no Pet weighs less than 1 pound.  I can either


Yes, this is exactly the way Spring works now.  It asks you to bind a
certain validator to a certain controller class.

The way my Attribute Validator works, is you place the validation =
attributes
on the domain object.  This way, the domain object has the validation =
meta
data attached to it.  All you need to bind is the generic =
AttributeValidator
class to each controller.  This way, one validator handles all domain
objects (as long as they have the validation rules bound to them, of =
course
:)

More and more it sounds like we're coming from two opposite ends.  No =
right
or wrong here, just very different.


| Or I can just go to my Pet.java source file and see them as=20
| source-level attributes.

Right, this is exactly what I do.  No need for a resolver now.



| commons-attributes?  However, that still doesn't cut out the need to
lookup
| the validator for a bean (aka command in spring-web) in order to kick


See above and my code.  I should put an example on the web site I put =
up.
That might explain everything.


General Explanation:

1 (singleton) AttributeValidator for webapp, implements spring.Validator =
N
controllers N command objects (the beans populated from the form)

1:1 controller:command object
1:1 controller:validator

1:M command object:attributes (validation rules)

So the command object has the validation rules in form of attributes. =
The
generic attributevalidator can look into the command object, get the
attributes, and do the validation.

Hope that helps.
Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFARmpg5EIB1scRes8RAuGyAJ9VTMEJ8u8Ss+Vj/RtVvWwzyhpJ+ACePtgr
HnkBdQsJSdJTWCrBQxsjUh8=3D
=3D0TbM
-----END PGP SIGNATURE-----