Menu
▾
▴
Re: [Springframework-developer] commons-validator adapter
|
From: <jue...@we...> - 2004-04-09 05:45:52
|
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
|
