Re: [Springframework-developer] Spring MVC and validation

[Steven D. <ste...@gm...>]

Hi Paul,

Have you looked at Valang already?

http://opensource2.atlassian.com/confluence/spring/display/MODULES/Using+Va=
lang+validator

It's a declarative validation language that has some powerful
constructs and its feature set is growing. It's build on top of
Spring's validation package. It currently isn't released yet but the
code is stable and a lot of people use it in production.

Steven

On 9/11/05, Paul Sundling <tk...@tk...> wrote:
> I've been pretty successful getting core Spring in my organization so
> far, with 5 other developers now that have touched it.  Thanks for the
> quick turn around on my last feature request.  You guys rock!
>=20
> In less than a month I plan to do a presentation on Spring MVC.  I'm
> planning to advocate Spring MVC as a possible next generation
> architecture.  Struts is already available in the prototype stage and is
> moving ahead.  I'd like to put together a Spring MVC prototype to
> challenge it before Struts becomes a corporate standard.  Overall Spring
> MVC compares well, but the lack of more complete common validation
> support is a major point in Struts favor. The auto generated javascript
> to go with validation was nice too.  It should be easy to mix built in
> validation with custom validation like you can do when extending Struts
> ValidatorForm.
>=20
> There is already org.springframework.validation.ValidationUtils , but it
> has only support for the most basic validation (rejectIfEmpty and
> rejectIfEmptyAndWhitespace).  There is also the Spring Modules
> (https://springmodules.dev.java.net/) commons validator integration,
> which is at 0.2 and is does not even have rudimentary documentation in
> place yet.  There is Aurora MVC (http://www.auroramvc.org/aurora-
> web/docs/html/validation.html) which builds on top of Spring MVC.  Of
> course, there is always creating them programmatically too.  I'm
> guessing lots of Spring MVC programmers working on big projects probably
> have homegrown utility classes for this...
>=20
> It seems that are a proliferation of approaches on how to deal with
> common validations that always come up.  For those experienced with
> Struts, it's a normal expectation that a developer doesn't have to write
> their own email validation code...
>=20
> I'm willing to roll up my sleeves and help if needed.  I have had
> patches commited on Struts and Maven.  I'll preface this by saying that
> I haven't done a thorough analysis of the source code of various
> options.  I apologize in advance if the message is therefor naive.
>=20
> So what should be done here?  Here are some possible approaches that I
> was thinking about.
>=20
> 1) Add more basic validations to
> org.springframework.validation.ValidationUtils like RejectInvalidEmail
> and RejectOutsideDateRange.  This could get large since there are 4
> signature variations of each validation.
> 2) Polish up the Spring Modules commons validator integration and roll
> it in Spring MVC.  I'm not sure how production ready the code is, but
> there are only a dozen classes, so it's probably not too complicated.
> 3) Add docs and examples to the Spring Modules and prominently mention
> it on the Spring site as a solution for common stuff and how production
> ready it is.
> 4) Everyone else feels things are fine the way they are and it's fine if
> developers just create homegrown utility classes for popular
> validations.
> 5) Some other option I haven't thought of...  <Your idea here.>
>=20
> So what is the plan?  What can I do to help?  The last big thread on
> this was back in May.
>=20
> Paul Sundling
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>