[Springframework-developer] Keep Spring Focused WAS: commons-validator adapter

[Brandon G. <ma...@ph...>]

Here is a summary of the previous threads that lead up to this discussion.
Please read an comment.

--- Brandon Goodin Mon 4/6/2004 ---

Do what you like. But, these are the same kind of near sighted arguments
I've heard from the Struts group over the last 2 years. If you provide
integrated support for commons validator NOW people will grow to be used to
it as "the Spring" solution. Then when you introduce the "real" Spring
declarative validation you will have competing products within the framework
creating confusion. If commons validator is NOT going to be the "official"
Spring declarative validation then keep it OUT of the core distro. I do not
believe you are keeping focused in doing these type of things. You CAN
support things and help to keep them focused WITHOUT making it part of the
core. Use a little collaboration for goodness sakes.

Brandon

--- Keith Donald Mon 4/6/2004 ---

Spring to me is about making it easier to build real applications quicker.
Since most applications (mine included) demand syntax and semantic
validation of business objects, I would argue a good declarative validation
framework managed by the Spring team is a good fit.  Personally, I don't
think commons-validator is that answer for us long term.  I think we can
offer better and do so in a "cleaner" (more true Spring) fashion, and that's
the focus of the 1.1 declarative validation efforts.  However, we recognize
a substantial number of people out there already have an investment in
Struts/commons-validator--thus for us to provide a  _thin_ adapter for it
that facilitates integration with the rest of Spring helps those people.
And taking responsiblity for managing that piece helps ensure it stays
consistent with the rest of the framework in terms of quality (including
documentation and test coverage.)

So my point is when I see that the Spring team has taken responsibility for
an area and put their name on it, that says something about its quality:
that is, that it is useful for one (it addresses a need, is documented, is
tested), and that it will be managed and supported carefully over time.  Rod
and Juergen are not going to move something out of the sandbox into the core
and into a release without first making sure it's ready and there is a real
need for it, for example.

We wouldn't want the emergence of a ton of decentralized Spring sub projects
to produce a sourceforge-like effect over time--that is, a lot of projects
that are inconsistent in terms of support-level/documentation/activity, etc
(and personally I prefer Spring as my one-stop-shop, reducing the headache
generally associated with managing technology integration [even then though,
it's still modular...]).   Please note this is not to say subprojects that
leverage Spring are a bad idea!  Heck no, just look at the new Acegi
Security Framework, for example!  There just needs to be a separation
between _what is_ Spring and what is a _separately managed_ project that
builds on Spring.

I agree we don't need a million validator options, and we should say "no" to
things that aren't a good fit or don't address a clear, substantial user
need.  So again the goal here is to allow those already with an investment
in commons-validator or Struts a way to easily integrate it with Spring.
The adapter is to be quite thin and optional and there for people wanting to
use Spring but also needing it.  Long term, I'd like to see everyone using
our own declarative validation stuff that we're working on now, because we
feel we can offer something better and with some unique capabilities.  But
it's not ready yet (and even if it was people can't be expected to migrate
everything on a dime, right?)

Keith

--- Brandon Goodin Mon 4/5/2004 ---

This is exactly what I mean. Thanks Karl. I hope developers of Spring take
what Karl is saying to heart. To me this is vitally important in keeping the
reality and perception of Spring light and focused. I would hate to see
Spring suffer from what Struts suffers from... "fascination with gadgetry"
or BSOS (Bright Shiny Object Syndrome)...distraction from what is important.

Any developers reading this?

Brandon

--- Karl Baum Mon 4/5/2004 ---

It's great that Spring offers a developer so many options, but after a while
it may be difficult to separate core Spring from the convenient add ons.
What must a developer read up on before he or she understands what spring is
really about?  I would tend to side towards IOC, AOP, and the BeanFactory
before the commons validator plugin, but this does not mean a commons
validator plugin is not a great idea (I for one am trying to integrate it
into my current project.).  Each plugin that is integrated directly into the
project is yet another responsibility for the community of Spring developers
when it comes to documentation and maintenance.  This documentation, with
all of the add ons and plugins, will eventually become so bloated, the
average developer may become overwhelmed by it's size and complexity.

Why not farm these plugins out to smaller subprojects with teams of
developers focused on delivering a specific add on to the Spring project.
This leaves everyone with all of the great Spring options, but in the end
the Spring Framework never loses site of it's purpose  This isn't just about
the commons validator project.  With each new popular open source component,
we will need yet another package checked into the Spring project.  We can
start now with the spring-commons-validator subproject.

--- Brandon Goodin Mon 4/5/2004 ---

I understand that. I'm simply saying... leave the choices on other websites
and focus on what spring is. Not on all the neat toys you can plug into it.
So, where do you draw the line on what does and does not get included. Why
not setup a directory of tools that can be used in spring instead of feeling
compelled to include support for every permutation into the distro or in the
spring cvs. Just cuz you can doesn't mean you should. I think moves like
this will cause confusion around spring not help it.

Brandon

--- Seth Ladd Mon 4/5/2004 ---

A nice aspect of Spring is that it attempts to give developers different
choices for a particular task.  For validation, commons-validator is just
one choice.  Other choices include metadata validator or programmatic
validation.  IMHO, the commons-validator fills a nice
niche: when you want to do declarative validation but can't mark up the
source code (if, for example, you're using generated source or 3rd party
classes).

With Spring, you get to Pick and Choose!
Seth.