RE: [Springframework-developer] Re: commons-validator adapter

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

ouch, yea I figured that was coming. :-)
=20
"expression" is one suggestion I have.  And to be honest, I'm not really
high on the term Predicate either.  I could rename that "Condition" - or =
we
could adopt Hibernate's Criteria term.
=20
That would result in:
    org.springframework.expression
    org.springframework.expression.conditions
    org.springframework.expression.functions
=20
It is possible to rename "functions" to "actions" as well.  But =
functions
imply a return value...
=20
I'm open to suggestions! Keith
=20
=20
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Rod Johnson
Sent: Thursday, April 08, 2004 3:21 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: commons-validator adapter



functor is truly horrible.
=20
I look forward to looking at this stuff in detail--it sounds cool--but I
think we must be able to find a better name :-)
=20

----- Original Message -----=20
From: Keith  <mailto:kd...@cs...> Donald=20
To: Daniel Miller <mailto:mi...@pa...> =20
Cc: spr...@li...=20
Sent: Thursday, April 08, 2004 2:44 AM
Subject: [Springframework-developer] Re: commons-validator adapter

Daniel,
=20
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.)
=20
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...)
=20
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.
=20
Keith
=20
----- Original Message -----=20

From: Daniel  <mailto:mi...@pa...> Miller=20
To: Keith Donald <mailto:kd...@cs...> =20
Sent: Wednesday, April 07, 2004 8:35 PM
Subject: RE: commons-validator adapter


Keith,
=20
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.
=20
I agree, we should probably refactor them to reuse and share as much =
code
between the commons and attributes validators as possible.
=20
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?
=20
I'll keep you posted with any bugs that I find.
=20
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,
=20
No problem.
=20
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.
=20
I'll keep you posted.  In the meantime if you find any bugs send 'em my =
way.
=20
Thanks,
Keith