[Springframework-developer] Re: commons-validator adapter

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

MessageDaniel,

The new declarative validation stuff will support both rule definition =
via source markup via attributes like you said, as well as a xml-based =
configuration via Spring IoC.  And there will still be the programmatic =
option for configuration (I'm a big believer in having a polished API =
that works just as well as the config files for those who still prefer =
that route.)

I think it's going to be quite powerful, more so than commons-validator, =
and easier to define new rules.  Right now you can define just about any =
validation expression you can think up using the rules API - and complex =
expressions (including compound expressions using And/Or/Not logical =
operators and all the standard binary operators) are possible.  For =
example, it's possible to define a rule that says: property "foo" is =
required if properties "bar" and "apple" are present, but not if =
"orange" is present.  If those rules change, the API is flexible enough =
tweak them without having to define a new class all together (the API =
provides very much a "building block" approach for composing rules.).  =
Similiary, you can say that property "foo" must be in the range of =
properties "lowBar" and "highBar" (or you can parameterize the property =
expressions and say that "foo" must be in the constant range of "1" to =
"255" for example...)

The predicate (rules) API is currently in the sandbox under =
src/sandbox/org/springframework/functor (functor might not be the best =
name for it - I just used it because the design is based on a functional =
style of programming (heavy on the strategy & chain of responsibility =
patterns) illustrated by commons-functor and Object space's JGL...) I =
think it is looking pretty good.  The next challenge -- what I am =
working on now -- is to integrate that API with a easy way of =
declaratively specifying rules in an external file/source attributes =
(basically nailing down that format, with emphasis on keeping the amount =
of config needed concise), and then hooking rule definition up to the =
validation results reporting classes for generating internationalized =
error messages and typing hints when bean validation occurs at runtime.  =
More advanced features include the ability to fire validation rules =
automatically when "constrained" set() methods are called on a javabean, =
either using AOP or the built in java-beans VetoChangeListener support.  =
The biggest challenge I've found there is figuring out, based on what =
rules effect what properties, which rules should fire on which set call. =
 That's not as easy as it seems when a single rule effects multiple =
properties.

Keith

----- Original Message -----=20
  From: Daniel Miller=20
  To: Keith Donald=20
  Sent: Wednesday, April 07, 2004 8:35 PM
  Subject: RE: commons-validator adapter


  Keith,

  My viewpoint for now is that if Juergen and Rod approve the code then =
its probably worth having it. I won't even be upset if it gets moved to =
a "spring-plugins" jar as long as it's made available for people to use.

  I agree, we should probably refactor them to reuse and share as much =
code between the commons and attributes validators as possible.

  I haven't had time to look at your attributes-based validator at all, =
so forgive me if I seem a bit ignorant. From what I understand, this =
attributes-based validation requires to be placed in the source code of =
the classes that would be validated. Is that correct? If so, is there =
any way we could create an XML configuration option like the =
Commons-Validator has (i.e. not dependent on attributes at all)? It =
would be really cool if it supported the same XML file format that the =
Commons-Validator does. What do you think?

  I'll keep you posted with any bugs that I find.

  Daniel
    -----Original Message-----
    From: Keith Donald [mailto:kd...@cs...]
    Sent: Tuesday, April 06, 2004 12:24 PM
    To: 'Daniel Miller'
    Subject: RE: commons-validator adapter


    Daniel,

    No problem.

    BTW - I didn't realize those were *struts* classes, I assumed they =
were commons-validator.  In that case it's probably going to be best for =
us to just refactor those classes against our own declarative validation =
support (which will provide a flexible API for defining rules.)  If you =
want to see some of the API in development, check out =
sandbox/src/org/springframework/functor/PredicateFactory.

    I'll keep you posted.  In the meantime if you find any bugs send 'em =
my way.

    Thanks,
    Keith