RE: [Springframework-developer] commons-validator adapter

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

Juergen,

The core rule interfaces and "building block" classes amount to about =
50K
total.  Most of that is weighted towards the convenience factory =
methods. =20

I don't anticipate that increasing more.  If we just wanted to include =
the
interfaces, we could get it down to about 15K or so.  The advantage of
making those core is they could be more easily reused in different parts =
of
the framework, because they really could be useful in general (any kind =
of
reusable function object could implement one of the Predicate/Function
interfaces, for example, and used for things like filters/pipes, for =
doing
extended bean definition property conversion & validation...or filtering
collections, or whatever...)

However, I agree, various rule implementations we and the user community
develop over time and integrate back will likely grow the library.  For
example, adding the Email Validator, the Date Validator, the Credit Card
Validator, the this-or-that validator.  And I agree the =
commons-validator
adapter should probably be separate from the core as well, since we'll =
be
offering something of our own.

Does it make sense to have part core and the part we anticipate growing =
over
time in a 'rules' (or something like that) subproject?  Or should we =
just
move everything over to a subproject for now, and if we decide that =
parts
are generally useful, factor them into the core at some later point?  I =
am
OK with either approach, the only concern I have about the latter is
isolating some generally useful stuff from the core framework and not =
taking
advantage simplfy b/c it might not get the same level of review.  Of =
course
the argument could be made that maybe it's better that the design prove
itself first.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Friday, April 09, 2004 1:44 AM
To: spr...@li...
Subject: Re: [Springframework-developer] commons-validator adapter


Keith,
=20
As the rules / declarative validation support is already becoming quite
extensive, I wonder whether it is worth creating an own subproject for =
it
(just like "spring-rcp"), maybe "spring-validation" (possibly getting =
the
word "declarative" in too)?
=20
Of course, the basic validation and binding infrastructure should remain =
in
the core Spring codebase. What I consider is to move all extended =
validation
support to a separate subproject. This would also include =
commons-validator
support, and possible future extensions.
=20
In terms of jar file sizes, the extended validation support in the =
sandbox
already amounts to more than 90 KB. I'd expect that people might request =
or
contribute more and more convenience rules over time, so I can imagine =
that
this will grow towards 150 KB or even more.
=20
My basic rule is that everything that's in the core Spring codebase goes
into spring.jar, which should cover typical usage scenarios. It's hard =
to
decide what goes in there, but I'm keen on not growing this =
significantly
beyond 1 MB. Things that have their own potential for rapid growth =
should
not go into the core.
=20
JMX and JMS support are definite candidates for the core, as they are =
rather
small, and I don't see the potential for extensive growth beyond the =
initial
versions there (in terms of size). Declarative validation on the other =
hand
has the potential to become a whole framework itself.
=20
What do you think? This would already give you two Spring subprojects =
then,
but hey, your output demands it ;-) Note that this would also allow for =
a
separate release schedule for the declarative validation project, just =
like
with the Rich Client Platform.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von
Keith Donald
Gesendet: Fr 09.04.2004 00:54
An: spr...@li...
Betreff: RE: [Springframework-developer] Re: commons-validator adapter



Since the purpose of this package is really to support the definition of
declarative rules (like validation rules, transformation/filter rules,
business rules, etc.) just plain old "org.springframework.rules" seems =
to
work.  It's simpler and more concise than expression, and definitely
functor.

I left the term Predicate as is for now, something about =
"BinaryCondition"
just doesn't sound right.  Attached below is a summary of the current =
layout
of the structure.  While there are a good many types, they're _small_ =
and
clients deal primarily with the Rules/PredicateFactory classes for
creating/composing rules (if using programatically), which is similar to
Hibernate's Criteria/Expression API.  Defining your own new rule =
conditions
is simple: just define a new Predicate implementation (which only =
requires
implementing a single test(arg) method.

For example: there is no EmailValidator class yet for validating String
properties that are e-mail addresses. To implement this we say:

public class EmailValidator implements UnaryPredicate {
        public boolean test(Object argument) {
                String email =3D (String)argument;
                return isEmailAddress(email);
        }

        private boolean isEmailAddress(String argument) {
                // the real work....
        }
}

Then, to create a rule that says a property is "required", has a "max
length" of 128 characters, and must be a "email address":

Rules.createRule("emailAddressProperty")
     .add(PredicateFactory.required())
     .add(PredicateFactory.maxLength(128))
     .add(EmailValidator.instance()); =20

The 'add' methods above imply a logical "AND" to all the predicates
(conjunction).   To get fancier, for example, to say that the argument =
is
valid regardless just as long as some other property is present (a =
top-level
OR condition) you can do something like this:

UnaryPredicate rules =3D
        PredicateFactory.or(
                PredicateFactory.
                    conjunction(new UnaryPredicate[] {
PredicateFactory.required(),

PredicateFactory.maxLength(128),

EmailValidator.instance()),
                =
PredicateFactory.propertyPresent("primaryEmailAddress"));

Rules.createRule("emailAddressProperty").add(rules);

That's a bit more complex, but it basically says: "emailAddressProperty =
is
valid if it is required, less than 128 characters, and an email address =
---
OR it's valid regardless as long as the primaryEmailAddress is present.

Just some examples.  This is much more than you can do with
commons-validator! :) Keith

Attached is a break down of the API to date (PLEASE NOTE THIS IS STILL =
VERY
EXPERIMENTAL & SUBJECT TO CHANGE!!!)

org.springframework.rules (your core interfaces and the API/factory for
composing rules programatically.)

Interfaces

BinaryFunction
        Evaluates two arguments and returns a single result.

BinaryPredicate
        Tests two arguments and returns a single boolean result.  A
conditional expression.

UnaryFunction
        Evaluates one argument and returns a single result.

UnaryPredicate
        Tests one argument and returns a single boolean result.  A
conditional expression.

Classes

Rules
        A factory for creating rules.

PredicateFactory
        A factory for easing the construction and composition of =
predicate
conditions.

FunctionFactory
        A factory for easing the construction and composition of =
functions.

LogicalOperator
        Type-safe enums for various conditional or logical operators
(AND/OR)

RelationalOperator
        Type-safe enum class for supported binary operators.

Algorithms
        Convenience utility class which provides a number of algorithms =
that
apply selection rules and filters to collections, for example.


org.springframework.rules.predicates (your rule condition building
blocks...)

BeanPropertyExpression
        A unary predicate that returns the result of a boolean =
expression
that tests two variable bean property values.

ParameterizedBeanPropertyExpression
        A unary predicate that returns the result of a boolean =
expression
that tests a variable bean property value against a constant parameter
value.

EqualTo
        Predicate that tests object equality (not identity.)

ComparisonBinaryPredicate
        Abstract helper superclass for binary predicates involved in
comparison operations.

GreaterThan
        Predicate that tests if one comparable object is greater than
another.

GreaterThanEqualTo
        Predicate that tests if one comparable object is greater than or
equal to another.

LessThan
        Predicate that tests if one comparable object is less than =
another.

LessThanEqualTo
        Predicate that tests if one comparable object is less than or =
equal
to another.

ParameterizedBinaryPredicate
        A unary predicate adapting a binary predicate that uses a
parameterized constant value as the second argument when testing.

UnaryFunctionResultConstraint
        Tests the result returned from evaluating a unary function.

BinaryFunctionResultConstraint
        Tests the result returned from evaluating a binary function =
against
some condition.

UnaryNot
        "Nots" another unary predicate (the inverse) by using =
composition.

CompoundUnaryPredicate
        Abstract base class for unary predicates which compose other
predicates.

UnaryAnd
        A "and" compound predicate (aka conjunction).

UnaryOr
        A "or" compound predicate (aka disjunction).

PropertyPresent
        Predicate that tests if the specified bean property is "present" =
-
that is, passes the "Required" test.

Range
        A range whose edges are defined by a minimum Comparable and a
maximum Comparable.

Required
        Validates a required property.


org.springframework.rules.functions (your "actions" or functions that do
things or execute if a predicate is true...)

Class Summary

GetProperty
        Binary function that gets a bean property.
Maximum
        Returns the maximum of two Comparable objects
Minimum
        Returns the maximum of two Comparable objects. StringLength
        Returns the Integer length of an object's string form, or zero =
if
the object is null. StringTrimmer
        Returns a trimmed copy of the string form of an object.
UnaryFunctionChain
        A chain of unary functions that evaluate their results in an =
ordered
sequence.

The abstract nature of many of the core classes demonstrates the =
"building
block approach" of taking simple little function objects and combining =
them
to create complex rules.  It's a bit different, but certainly
powerful/flexible.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Keith Donald
Sent: Thursday, April 08, 2004 3:02 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Re: commons-validator adapter


ouch, yea I figured that was coming. :-)

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

That would result in:
    org.springframework.expression
    org.springframework.expression.conditions
    org.springframework.expression.functions

It is possible to rename "functions" to "actions" as well.  But =
functions
imply a return value...

I'm open to suggestions! Keith


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

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 :-)

----- Original Message -----
From: Keith Donald
To: Daniel Miller
Cc: spr...@li...
Sent: Thursday, April 08, 2004 2:44 AM
Subject: [Springframework-developer] Re: commons-validator adapter


Daniel,

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 -----
From: Daniel Miller
To: Keith Donald
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



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer