springframework-developer

[Springframework-developer] RE: commons-validator adapter

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

Daniel,
=20
I put the spring-commons-validator.tld file in the sandbox at:
=20
    src/sandbox/org/springframework/web/servlet/tags
=20
I've initially set the optional short name as "Spring-Commons-Validator" =
and
the optional URI as =
http://www.springframework.org/tags/commons-validator
=20
Keith
=20
-----Original Message-----
From: Daniel Miller [mailto:mi...@pa...]=20
Sent: Friday, April 02, 2004 6:51 PM
To: Keith Donald
Subject: RE: commons-validator adapter


Keith,
=20
This just in from Karl Baum, who is using the same source that you =
recently
downloaded from my web space:
=20
        ...the uri and shorname element element in
spring-commonsvalidator.tld are:
=20
    <shortname>html</shortname>
    <uri>http://jakarta.apache.org/struts/tags-html</uri>
=20
Unless you know of any conflicts, I suggest that we set the shortname to
"scv" for "Spring Commons-Validator".
I guess the uri should be  <http://www.springframework.org/scv>
http://www.springframework.org/scv unless you have a better idea.
=20
You can go ahead and make these changes before you put the code in the
sandbox if you want.
=20
Thanks,
Daniel

[Springframework-developer] RE: commons-validator adapter

[Brandon G. <Bra...@pl...>]

commons validator? gack! Don't pollute spring with all of this crap. I
don't want to see spring turn into the 8000 pound gorilla that struts
has. Please consider making this stuff peripheral.

>>> kd...@cs... 4/5/2004 4:58:47 PM >>>
Daniel,
 
I put the spring-commons-validator.tld file in the sandbox at:
 
    src/sandbox/org/springframework/web/servlet/tags
 
I've initially set the optional short name as
"Spring-Commons-Validator" and the optional URI as
http://www.springframework.org/tags/commons-validator
 
Keith
 
-----Original Message-----
From: Daniel Miller [mailto:mi...@pa...] 
Sent: Friday, April 02, 2004 6:51 PM
To: Keith Donald
Subject: RE: commons-validator adapter

Keith,
 
This just in from Karl Baum, who is using the same source that you
recently downloaded from my web space:
 
        ...the uri and shorname element element in
spring-commonsvalidator.tld are:
 
    <shortname>html</shortname>
    <uri>http://jakarta.apache.org/struts/tags-html</uri>
 
Unless you know of any conflicts, I suggest that we set the shortname
to "scv" for "Spring Commons-Validator".
I guess the uri should be http://www.springframework.org/scv unless you
have a better idea.
 
You can go ahead and make these changes before you put the code in the
sandbox if you want.
 
Thanks,
Daniel

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

[Seth L. <se...@eh...>]

Brandon Goodin wrote:
> commons validator? gack! Don't pollute spring with all of this crap. I 
> don't want to see spring turn into the 8000 pound gorilla that struts 
> has. Please consider making this stuff peripheral.


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

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

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

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.

B

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Seth Ladd
Sent: Monday, April 05, 2004 5:29 PM
To: spr...@li...
Subject: Re: [Springframework-developer] RE: commons-validator adapter

Brandon Goodin wrote:
> commons validator? gack! Don't pollute spring with all of this crap. I 
> don't want to see spring turn into the 8000 pound gorilla that struts 
> has. Please consider making this stuff peripheral.


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


-------------------------------------------------------
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_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

[Baum, K. <Kar...@Ta...>]

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.

----- Original Message -----
From: "Brandon Goodin" <ma...@ph...>
To: <spr...@li...>
Sent: Monday, April 05, 2004 10:08 PM
Subject: RE: [Springframework-developer] RE: commons-validator adapter


> 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.
>
> B
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
Of
> Seth Ladd
> Sent: Monday, April 05, 2004 5:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
> Brandon Goodin wrote:
> > commons validator? gack! Don't pollute spring with all of this crap. I
> > don't want to see spring turn into the 8000 pound gorilla that struts
> > has. Please consider making this stuff peripheral.
>
>
> 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
>
>
> -------------------------------------------------------
> 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_id=3638&op=click
> _______________________________________________
> 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_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

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

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

P.S. How are you doing Karl? :D Haven't talked to you since struts-chain. I
bailed on it in hopes of what Spring is offering.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Baum, Karl
Sent: Monday, April 05, 2004 8:33 PM
To: spr...@li...
Subject: Re: [Springframework-developer] RE: commons-validator adapter

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.

----- Original Message -----
From: "Brandon Goodin" <ma...@ph...>
To: <spr...@li...>
Sent: Monday, April 05, 2004 10:08 PM
Subject: RE: [Springframework-developer] RE: commons-validator adapter


> 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.
>
> B
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
Of
> Seth Ladd
> Sent: Monday, April 05, 2004 5:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
> Brandon Goodin wrote:
> > commons validator? gack! Don't pollute spring with all of this crap. I
> > don't want to see spring turn into the 8000 pound gorilla that struts
> > has. Please consider making this stuff peripheral.
>
>
> 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
>
>
> -------------------------------------------------------
> 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_id=3638&op=click
> _______________________________________________
> 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_id=3638&op=click
> _______________________________________________
> 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_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

[Colin S. <col...@ex...>]

Putting on my pundit cap, some people might say the what Struts suffers 
most from is bad design :-)

Brandon Goodin wrote:

>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
>
>P.S. How are you doing Karl? :D Haven't talked to you since struts-chain. I
>bailed on it in hopes of what Spring is offering.
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Baum, Karl
>Sent: Monday, April 05, 2004 8:33 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
>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.
>
>----- Original Message -----
>From: "Brandon Goodin" <ma...@ph...>
>To: <spr...@li...>
>Sent: Monday, April 05, 2004 10:08 PM
>Subject: RE: [Springframework-developer] RE: commons-validator adapter
>
>
>  
>
>>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.
>>
>>B
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On Behalf
>>    
>>
>Of
>  
>
>>Seth Ladd
>>Sent: Monday, April 05, 2004 5:29 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>>
>>Brandon Goodin wrote:
>>    
>>
>>>commons validator? gack! Don't pollute spring with all of this crap. I
>>>don't want to see spring turn into the 8000 pound gorilla that struts
>>>has. Please consider making this stuff peripheral.
>>>      
>>>
>>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
>>    
>>

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

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

This is not a bash struts thread. It worked for it's season. This is a
"please keep Spring focused" thread. Please, focus your comments towards
that effort.

Brandon

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Colin Sampaleanu
Sent: Tuesday, April 06, 2004 6:52 AM
To: spr...@li...
Subject: Re: [Springframework-developer] RE: commons-validator adapter

Putting on my pundit cap, some people might say the what Struts suffers 
most from is bad design :-)

Brandon Goodin wrote:

>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
>
>P.S. How are you doing Karl? :D Haven't talked to you since struts-chain. I
>bailed on it in hopes of what Spring is offering.
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Baum, Karl
>Sent: Monday, April 05, 2004 8:33 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
>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.
>
>----- Original Message -----
>From: "Brandon Goodin" <ma...@ph...>
>To: <spr...@li...>
>Sent: Monday, April 05, 2004 10:08 PM
>Subject: RE: [Springframework-developer] RE: commons-validator adapter
>
>
>  
>
>>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.
>>
>>B
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On Behalf
>>    
>>
>Of
>  
>
>>Seth Ladd
>>Sent: Monday, April 05, 2004 5:29 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>>
>>Brandon Goodin wrote:
>>    
>>
>>>commons validator? gack! Don't pollute spring with all of this crap. I
>>>don't want to see spring turn into the 8000 pound gorilla that struts
>>>has. Please consider making this stuff peripheral.
>>>      
>>>
>>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
>>    
>>



-------------------------------------------------------
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_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

[Rod J. <rod...@in...>]

Guys

We are aware of the dangers here. We do not want Spring to become bloated,
and it won't.

So far we have the following strategies:

- ** Keep the core separate from the add-ons ** E.g. the IoC container
doesn't
even depend on AOP, let alone Commons Validator/whatever. This means that
it's possibly to use say the BeanFactory or JDBC without extensive
dependencies: indeed, the whole of Spring (except integration) without
extensive dependencies.
- Keep the focus of the core developers on the core.
- Set the bar high in terms of the quality of what we accept. This is one
argument for keeping commonly-used add-ins in the Spring project.
Let's suppose we don't address integration with a popular product such as
Quartz. Several Spring/Quartz libraries then emerge, all but one of them
bad. Now users are confused and it reflects poorly on Spring.
- Ensure that the correct message gets out. Marketing is important. We must
ensure that people know that the core doesn't depend on the extensions.

However, I think this thread does show that we need to be careful in
accepting too many add-ons into the core. Perhaps we could have an add-ons
project for the second tier of integration: e.g. Hibernate is obviously
core, Commons Validator could be shipped along with a Spring addons
distribution, but which is still under the Spring Framework umbrella. Such
integrations likely to be used commonly are definitely in a separate
category from integration with highly specialized products, that are
unlikely to see wide use. And we can always promote code into Spring proper.

Perhaps all integrations could start off in the add-ons project, and only be
promoted if there's user demand.

Regarding documentation, good point, we should separate out the core from
the add ons. Maybe 2 volumes of the reference manual. Also perhaps we should
provide a section on the web site helping users to understand what they need
to understand. This could be geared to real user situations, like "web
development with Hibernate", "looking for a replacement for SLSBs", "looking
for quicker/easier JDBC".

Regards,
Rod

----- Original Message -----
From: "Baum, Karl" <Kar...@Ta...>
To: <spr...@li...>
Sent: Tuesday, April 06, 2004 4:33 AM
Subject: Re: [Springframework-developer] RE: commons-validator adapter


> 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.
>
> ----- Original Message -----
> From: "Brandon Goodin" <ma...@ph...>
> To: <spr...@li...>
> Sent: Monday, April 05, 2004 10:08 PM
> Subject: RE: [Springframework-developer] RE: commons-validator adapter
>
>
> > 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.
> >
> > B
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behalf
> Of
> > Seth Ladd
> > Sent: Monday, April 05, 2004 5:29 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] RE: commons-validator adapter
> >
> > Brandon Goodin wrote:
> > > commons validator? gack! Don't pollute spring with all of this crap. I
> > > don't want to see spring turn into the 8000 pound gorilla that struts
> > > has. Please consider making this stuff peripheral.
> >
> >
> > 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
> >
> >
> > -------------------------------------------------------
> > 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_id=3638&op=click
> > _______________________________________________
> > 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_id=3638&op=click
> > _______________________________________________
> > 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_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

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

[Tim C. <tc...@ta...>]

I know that I'm new to the Spring world but just to make another note on 
this subject.
Anyone that is on the Struts dev list can tell you that the latest 
release of Commons Validator has been a huge sticking point in the 
release of a new Struts version. I don't want to see the same thing 
happen to Spring as to XDoclet neither as though on THAT list can tell 
you. XDoclet has 10million dependencies (ok.. I exaggerate.. 999,999 
dependencies) and most of them are broken which results in a XDoclet2 
that does not build out of CVS. VERY VERY aggrevating.
Can I make a suggestion and vote to take a page from Maven's book?
Let's create a Spring-Plugin project of these "add-ons" they never have 
to get mixed with the main code and the main code will NEVER have to 
break due to breakages in the plugin's dependencies.
Even with this course the developers should still be careful what goes 
into the core of course. XDoclet 2 came up with that same architecture 
but unfortunately it's own core was tied too closely with other 
*currently* broken packages.
-Tim

Rod Johnson wrote:

>Guys
>
>We are aware of the dangers here. We do not want Spring to become bloated,
>and it won't.
>
>So far we have the following strategies:
>
>- ** Keep the core separate from the add-ons ** E.g. the IoC container
>doesn't
>even depend on AOP, let alone Commons Validator/whatever. This means that
>it's possibly to use say the BeanFactory or JDBC without extensive
>dependencies: indeed, the whole of Spring (except integration) without
>extensive dependencies.
>- Keep the focus of the core developers on the core.
>- Set the bar high in terms of the quality of what we accept. This is one
>argument for keeping commonly-used add-ins in the Spring project.
>Let's suppose we don't address integration with a popular product such as
>Quartz. Several Spring/Quartz libraries then emerge, all but one of them
>bad. Now users are confused and it reflects poorly on Spring.
>- Ensure that the correct message gets out. Marketing is important. We must
>ensure that people know that the core doesn't depend on the extensions.
>
>However, I think this thread does show that we need to be careful in
>accepting too many add-ons into the core. Perhaps we could have an add-ons
>project for the second tier of integration: e.g. Hibernate is obviously
>core, Commons Validator could be shipped along with a Spring addons
>distribution, but which is still under the Spring Framework umbrella. Such
>integrations likely to be used commonly are definitely in a separate
>category from integration with highly specialized products, that are
>unlikely to see wide use. And we can always promote code into Spring proper.
>
>Perhaps all integrations could start off in the add-ons project, and only be
>promoted if there's user demand.
>
>Regarding documentation, good point, we should separate out the core from
>the add ons. Maybe 2 volumes of the reference manual. Also perhaps we should
>provide a section on the web site helping users to understand what they need
>to understand. This could be geared to real user situations, like "web
>development with Hibernate", "looking for a replacement for SLSBs", "looking
>for quicker/easier JDBC".
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "Baum, Karl" <Kar...@Ta...>
>To: <spr...@li...>
>Sent: Tuesday, April 06, 2004 4:33 AM
>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
>
>  
>
>>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.
>>
>>----- Original Message -----
>>From: "Brandon Goodin" <ma...@ph...>
>>To: <spr...@li...>
>>Sent: Monday, April 05, 2004 10:08 PM
>>Subject: RE: [Springframework-developer] RE: commons-validator adapter
>>
>>
>>    
>>
>>>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.
>>>
>>>B
>>>
>>>-----Original Message-----
>>>From: spr...@li...
>>>[mailto:spr...@li...] On Behalf
>>>      
>>>
>>Of
>>    
>>
>>>Seth Ladd
>>>Sent: Monday, April 05, 2004 5:29 PM
>>>To: spr...@li...
>>>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>>>
>>>Brandon Goodin wrote:
>>>      
>>>
>>>>commons validator? gack! Don't pollute spring with all of this crap. I
>>>>don't want to see spring turn into the 8000 pound gorilla that struts
>>>>has. Please consider making this stuff peripheral.
>>>>        
>>>>
>>>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
>>>
>>>
>>>-------------------------------------------------------
>>>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_id=3638&op=click
>>>_______________________________________________
>>>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_id=3638&op=click
>>>_______________________________________________
>>>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_id=3638&op=click
>>_______________________________________________
>>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_id=3638&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>  
>

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

[Seth L. <se...@eh...>]

> you. XDoclet has 10million dependencies (ok.. I exaggerate.. 999,999 
> dependencies) and most of them are broken which results in a XDoclet2 
> that does not build out of CVS. VERY VERY aggrevating.
> Can I make a suggestion and vote to take a page from Maven's book?
> Let's create a Spring-Plugin project of these "add-ons" they never have 
> to get mixed with the main code and the main code will NEVER have to 
> break due to breakages in the plugin's dependencies.

That's a great point, and which is why I never build against CVS. 
Here's where maven is nice: it let's you specify a particular version of 
a jar as a dependency and then your project is stuck with that.  You 
become immune to all the new versions of that jar (which can be very 
dangerous).  If you're not using maven, you could just capture any jars 
needed for compilation/runtime and check them into your project's source 
control.  The same effect is achieved: locking into a version of a 
dependency.

So far, the Spring developers have done a great job in not introducing 
any code into the source tree that would jeopardize the integrity of the 
project or the build process.  Many, including myself, view Spring as 
production ready code and not a playground (which is how I view 
xdoclet2, for instance).  I trust the Spring developers to Do The Right 
Thing.

Seth

ps OK, I've got to be quiet now and get some work done. :)

[Springframework-developer] RE: commons-validator adapter

[Daniel M. <mi...@pa...>]

Hello all,

To those that are worried about Spring breaking due to dependencies: have
you looked at the code for the Commons-Validator adaptor for Spring? Spring
certainly doesn't depend on any of those few small classes, and I would be
the first to say that the core of Spring should _never_ depend on them. I
contributed the code because I found Spring lacking a declarative validation
solution and I happened to have been using the Commons-Validator. Many
people out there also use the Commons-Validator; an adaptor for Spring is
one more reason to migrate from whatever other framework they are currently
tied into.

In my opinion, the major problem with the Commons-Validator as it was in
Struts was the difficulty involved in adding custom validation routines.
With Spring, this problem has disappeared. A Commons-Validator-backed
beanValidator can easily be wired into any custom validation class. With
this strategy, you can even conditionally execute the Commons-Validation
based on the outcome of other validations.

Having said all of that, I will say that I would give my personal blessing
to moving the adaptor I wrote into a separate "spring-plugins" jar that
would be distributed with Spring--like the other jars distributed with
Spring except that the code wouldn't be included in Spring.jar--or available
as a separate download linked from the Spring site. A close connection to
and easy availability of the plugins with the main Spring project is very
important. Part of the reason I chose Spring in the first place was its
_built-in_ support for so many different technologies. I really like being
able to drop a single Spring.jar into my lib dir and have all of the support
code needed to interface with other projects right there waiting to be used.
It saves me a lot of precious development time searching and researching
where to download the most recent, yet most compatible version of each
plugin.

Daniel Miller

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Tim Chen
Sent: Tuesday, April 06, 2004 5:48 PM
To: spr...@li...
Subject: Re: [Springframework-developer] RE: commons-validator adapter


I know that I'm new to the Spring world but just to make another note on
this subject.
Anyone that is on the Struts dev list can tell you that the latest
release of Commons Validator has been a huge sticking point in the
release of a new Struts version. I don't want to see the same thing
happen to Spring as to XDoclet neither as though on THAT list can tell
you. XDoclet has 10million dependencies (ok.. I exaggerate.. 999,999
dependencies) and most of them are broken which results in a XDoclet2
that does not build out of CVS. VERY VERY aggrevating.
Can I make a suggestion and vote to take a page from Maven's book?
Let's create a Spring-Plugin project of these "add-ons" they never have
to get mixed with the main code and the main code will NEVER have to
break due to breakages in the plugin's dependencies.
Even with this course the developers should still be careful what goes
into the core of course. XDoclet 2 came up with that same architecture
but unfortunately it's own core was tied too closely with other
*currently* broken packages.
-Tim

Rod Johnson wrote:

>Guys
>
>We are aware of the dangers here. We do not want Spring to become bloated,
>and it won't.
>
>So far we have the following strategies:
>
>- ** Keep the core separate from the add-ons ** E.g. the IoC container
>doesn't
>even depend on AOP, let alone Commons Validator/whatever. This means that
>it's possibly to use say the BeanFactory or JDBC without extensive
>dependencies: indeed, the whole of Spring (except integration) without
>extensive dependencies.
>- Keep the focus of the core developers on the core.
>- Set the bar high in terms of the quality of what we accept. This is one
>argument for keeping commonly-used add-ins in the Spring project.
>Let's suppose we don't address integration with a popular product such as
>Quartz. Several Spring/Quartz libraries then emerge, all but one of them
>bad. Now users are confused and it reflects poorly on Spring.
>- Ensure that the correct message gets out. Marketing is important. We must
>ensure that people know that the core doesn't depend on the extensions.
>
>However, I think this thread does show that we need to be careful in
>accepting too many add-ons into the core. Perhaps we could have an add-ons
>project for the second tier of integration: e.g. Hibernate is obviously
>core, Commons Validator could be shipped along with a Spring addons
>distribution, but which is still under the Spring Framework umbrella. Such
>integrations likely to be used commonly are definitely in a separate
>category from integration with highly specialized products, that are
>unlikely to see wide use. And we can always promote code into Spring
proper.
>
>Perhaps all integrations could start off in the add-ons project, and only
be
>promoted if there's user demand.
>
>Regarding documentation, good point, we should separate out the core from
>the add ons. Maybe 2 volumes of the reference manual. Also perhaps we
should
>provide a section on the web site helping users to understand what they
need
>to understand. This could be geared to real user situations, like "web
>development with Hibernate", "looking for a replacement for SLSBs",
"looking
>for quicker/easier JDBC".
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "Baum, Karl" <Kar...@Ta...>
>To: <spr...@li...>
>Sent: Tuesday, April 06, 2004 4:33 AM
>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
>
>
>
>>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.
>>
>>----- Original Message -----
>>From: "Brandon Goodin" <ma...@ph...>
>>To: <spr...@li...>
>>Sent: Monday, April 05, 2004 10:08 PM
>>Subject: RE: [Springframework-developer] RE: commons-validator adapter
>>
>>
>>
>>
>>>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.
>>>
>>>B
>>>
>>>-----Original Message-----
>>>From: spr...@li...
>>>[mailto:spr...@li...] On Behalf
>>>
>>>
>>Of
>>
>>
>>>Seth Ladd
>>>Sent: Monday, April 05, 2004 5:29 PM
>>>To: spr...@li...
>>>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>>>
>>>Brandon Goodin wrote:
>>>
>>>
>>>>commons validator? gack! Don't pollute spring with all of this crap. I
>>>>don't want to see spring turn into the 8000 pound gorilla that struts
>>>>has. Please consider making this stuff peripheral.
>>>>
>>>>
>>>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
>>>
>>>
>>>-------------------------------------------------------
>>>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_id=3638&op=click
>>>_______________________________________________
>>>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_id=3638&op=click
>>>_______________________________________________
>>>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_id=3638&op=click
>>_______________________________________________
>>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_id=3638&op=click
>_______________________________________________
>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_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

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

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

----- Original Message ----- 
From: "Brandon Goodin" <ma...@ph...>
To: <spr...@li...>
Sent: Monday, April 05, 2004 10:08 PM
Subject: RE: [Springframework-developer] RE: commons-validator adapter


> 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.
>
> B
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
Of
> Seth Ladd
> Sent: Monday, April 05, 2004 5:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
> Brandon Goodin wrote:
> > commons validator? gack! Don't pollute spring with all of this crap. I
> > don't want to see spring turn into the 8000 pound gorilla that struts
> > has. Please consider making this stuff peripheral.
>
>
> 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
>
>
> -------------------------------------------------------
> 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_id=3638&op=click
> _______________________________________________
> 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_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

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

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

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Keith Donald
Sent: Tuesday, April 06, 2004 1:02 AM
To: spr...@li...
Subject: Re: [Springframework-developer] RE: commons-validator adapter

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

----- Original Message ----- 
From: "Brandon Goodin" <ma...@ph...>
To: <spr...@li...>
Sent: Monday, April 05, 2004 10:08 PM
Subject: RE: [Springframework-developer] RE: commons-validator adapter


> 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.
>
> B
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
Of
> Seth Ladd
> Sent: Monday, April 05, 2004 5:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
> Brandon Goodin wrote:
> > commons validator? gack! Don't pollute spring with all of this crap. I
> > don't want to see spring turn into the 8000 pound gorilla that struts
> > has. Please consider making this stuff peripheral.
>
>
> 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
>
>
> -------------------------------------------------------
> 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_id=3638&op=click
> _______________________________________________
> 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_id=3638&op=click
> _______________________________________________
> 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_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[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

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

[Rod J. <rod...@in...>]

Messagefunctor 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 -----=20
  From: Keith Donald=20
  To: Daniel Miller=20
  Cc: spr...@li...=20
  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 -----=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

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

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

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

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());=09

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(),
=20
PredicateFactory.maxLength(128),
=20
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.=20
=20
Classes=20

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)=20

RelationalOperator
	Type-safe enum class for supported binary operators.=20

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

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.)=20

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

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

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

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

LessThanEqualTo
	Predicate that tests if one comparable object is less than or equal
to another.=20
=20
ParameterizedBinaryPredicate
	A unary predicate adapting a binary predicate that uses a
parameterized constant value as the second argument when testing.=20

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

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).=20

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

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=20

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

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 -----=20
From: Keith Donald=20
To: Daniel Miller=20
Cc: spr...@li...=20
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 -----=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

Re: [Springframework-developer] commons-validator adapter

[<jue...@we...>]

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

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