[Springframework-developer] Spring MVC and validation

[Paul S. <tk...@tk...>]

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!

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.

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...

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...

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.

So what should be done here?  Here are some possible approaches that I
was thinking about.

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.> 

So what is the plan?  What can I do to help?  The last big thread on
this was back in May.

Paul Sundling