Re: [Springframework-developer] RE: validation stuff

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

Seth,

Those abstractions I'm talking about actually do make the code simpler and
decouple the validation processing with the metadata (configuration) API.
Furthermore, they form the basis for the cache I'm talking about.  They
introduce a few new interfaces yet, but they're simple interfaces.  And you
don't have to deal with them, as I mentioned in my last email - your
interface is exactly the same (aside from our two classname differences.)

Another benefit of those abstractions is they make it easier for the
validator be used in other contexts.  For example, maybe I want a
ValidationInterceptor which can take any bean, look up its validator, and
invoke the validation methods -- maybe as part of a command framework.  Or
maybe I want to wrap a domain object in a AOP proxy that invokes a
BeanValidator when set() methods are called.  Maybe I want validation rules
to come from another source other than attributes metadata.  That's easier
to do with the domain abstractions around than with the metadata stuff all
coupled in with your validation processing logic...

I agree completely we should use Errors.  What I would like to do is take
the best parts of your design and take the parts of mine I feel are strong
and merge the two in the sandbox for review.  Nothings going to be
complicated, hopefully simplified.  If something doesn't meet your
requirements, let me know immediately!  I'll work with you to get our stuff
committed ASAP.

Keith

----- Original Message ----- 
From: "Seth Ladd" <se...@eh...>
To: <spr...@li...>
Sent: Wednesday, March 03, 2004 8:16 PM
Subject: Re: [Springframework-developer] RE: validation stuff


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> | 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.
>
>
> That is a great idea.  AttributeValidator should cache the validation
> rules it finds for each command class.  Since AttributeValidator will
> usually be used as a singleton, this might help and cut down on the
> reflection and attribute discovery.
>
> Hopefully I'll be allowed to checkin the current Attribute Validator and
> we can start flushing it out.  I'm not sure what we gain from all those
> levels of abstraction you have proposed.  One of the nice things I like
> about the current attribute validator is that it doesn't introduce any
> new classes or interfaces; it tries to remain small and simple.
>
> But again, maybe those abstractions should remain only in the RCP
> project.  Once they've proved themselves as useful to a more general
> validation API (the current Spring one) we can integrate them.  I'm not
> anti-abstractions, I just haven't seen the need for them (yet).
>
> I don't want to lose the Errors interface from the validation API.  It's
> integrated into Spring already and other APIs (like the JSP tags)
> already work with it.
>
> Seth
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFARoNc5EIB1scRes8RAlNDAJ4h0aewSC4PGm8F06VBnvzFJ5u+4QCeOIMD
> FLOsi9/0fHkUAESpEbY+3Cc=
> =3/Qn
> -----END PGP SIGNATURE-----
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer