Re: [Springframework-developer] Commons-Validator for Spring

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Daniel,

One other thing: I agree Seth's idea and patch for using
MessageSourceResolvable's as arguments of other MessageResourceResolvables
for recursively resolving arguments using a message source is a slick idea
and we need it.  I will be working on getting that integrated.

Keith

----- Original Message ----- 
From: "Keith Donald" <kd...@cs...>
To: <spr...@li...>
Sent: Friday, March 05, 2004 8:33 AM
Subject: Re: [Springframework-developer] Commons-Validator for Spring

> Daniel,
>
> I can take a look at it.  I'm curious if it is feasible to use the same
> declarative validator design we're developing and apply another mechanism
> (adapter) for configuration from commons-validator's format.  That'd be
> nice, because we could use the same framework for all sources of
> configuration.  I know I am already doing this in my implementation on my
> system as I use Spring IoC for configuration, while Seth uses attributes.
> But that might prove to be too much work, and that your way is better
> overall.  I really can't say yet.
>
> commons-validator handles javascript validation client-side, too, right?
> Your adapter enables that? I know that's one area we have not addressed.
> Keith
>
> ----- Original Message ----- 
> From: "Daniel Miller" <mi...@pa...>
> To: <spr...@li...>
> Sent: Friday, March 05, 2004 12:10 AM
> Subject: RE: [Springframework-developer] Commons-Validator for Spring
>
>
> > Seth and Keith,
> >
> > Did you get a chance to look at my commons-validator adaptor? I was
> > wondering if you had any feedback? Feel free to tell me that it sucks,
or
> > that it was so elementary that you didn't want to waste any more time
> > talking to me about it :)
> >
> > I don't know much about commons-attributes, but from what I've been
> picking
> > up between the lines on your recent validator-related posts it's quite
> > different from the commons-validator approach. The main difference seems
> to
> > be that validation meta-data is expressed directly in the source of the
> bean
> > to be validated, while the commons-validator approach uses the
> > validation.xml file to hold all of that meta-data.
> >
> > Your attributes validator sounds a bit more powerful than the commons
> > validator, but many of the objects that I want to validate are generated
> (by
> > Middlegen) and I have no way of adding meta-data to the objects without
> > modifying the generated code. Of course, I could just write a wrapper
for
> > each object that I want to validate, but I might as well just write a
> > validator class for each object. That being said, I think there is room
> for
> > both an attributes validator and a commons validator in the Spring
> > framework.
> >
> > The main thing I am interested in knowing is the patch that you (Seth)
> > posted to allow message resources to be nested (as arguments) in another
> > message resource. Do you have any idea how soon this will make its way
> into
> > a Spring release or should I just get the source and build it in for my
> own
> > use?
> >
> > Thanks,
> > Daniel
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On Behalf
> > Of Daniel Miller
> > Sent: Tuesday, March 02, 2004 12:19 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Commons-Validator for Spring
> >
> >
> > Seth,
> >
> > That looks great. This would make my validation support super easy to
> > implement. You can grab my current source here:
> >
> >
>
http://www.paonline.com/millerd/Spring-commons-validator_no-dependencies.zip
> >
> > I have not had time to write up a good example, tests, or complete the
> > documentation. Hopefully I will be able to do this soon.
> >
> > Thanks,
> > Daniel
> >
> >
> > Original Message: -----------------------------------------------------
> >
> > | (2) Improve the handling of Errors objects to allow message resources
> > to be
> > | specified as arguments that would not be resolved to their
corresponding
> > | messages until reaching the view. I really like this solution, but I
> have
> > | not thought it through completely. One more note: since the errorArgs
> > | parameter is an array of Objects (not an array of Strings), maybe
there
> > | would be a way to use a "Message" object that would be resolved at a
> later
> > | time, while preserving the current functionality of Strings that are
> used
> > | directly as arguments. For all I know, there is already a way to do
> > this (it
> > | seems logical enough), and I just don't know about it. This J2EE stuff
> > is so
> > | hard to keep up with...
> >
> > Daniel,
> >
> > I just posted a simple patch w/ unit test for the functionality we've
> > discussed.  Please review and see if it meets your needs.
> >
> >
>
http://opensource.atlassian.com/projects/spring/secure/ViewIssue.jspa?key=SP
> > R-56
> >
> >
> > Seth
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> > -------------------------------------------------------
> > 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
>