springframework-developer — Spring Framework developers list

RE: [Springframework-developer] declarative validation rules interfaces

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

Sam,

Yea, your interceptor could use the source to lookup a validator by =
command
class, which would return you a BeanValidator instance for that command.
Each BeanValidator has the workflow to validate the entire bean, =
including
all properties, and nested beans.  Or you could just use the
ValidationService, where you directly pass in the command bean instance =
and
it'll look up the BeanValidator for you and use it (which I would
recommend.)  The service is basically just a thin fa=E7ade that =
abstracts that
lookup API away from you and lets you vary where validators are loaded
from...

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
sam...@ma...
Sent: Thursday, March 04, 2004 10:32 AM
To: spr...@li...
Subject: Re: [Springframework-developer] declarative validation rules
interfaces


Looks fantastic Keith. I guess I just have to write a simple
ValidationInterceptor to call the ValidationSource....with that in mind =
I've
posted a simple overview diagram showing how my commands get executed =
and
invoked at my blog here: =
http://www.magpiebrain.com/archives/000189.html. We
could do with a Wiki or website for this stuff perhaps - would make
documenting spring-rcp a little easier...

sam

Quoting Keith Donald <kd...@cs...>:

> How does this look -  I propose one interface you have to deal with to =

> the entire declarative validation subsystem.  Let me know what you=20
> think:
> =20
> public interface Validator {
>     public boolean supports(Class beanClass);
>     public void validate(Object bean, Errors errors);
> }
> =20
> Look familiar? It's the existing spring Validator interface! We can=20
> use it and have a ValidationService implementation that uses a=20
> AttributesValidatorSource to load individual validators using=20
> commons-attributes.
> =20
> This provides:
> =20
> - 100% backwards compatablility since the core interface is exactly=20
> what we deal with now for 'programmatic' validators.
> =20
> - A single implementation -- ValidationService -- that encapsulates=20
> the workflow for invoking the various declarative validators and=20
> collecting the results.  This implementation is independent of any=20
> source of validation rules (like via attributes.)  This allows us to=20
> vary the source without impacting the processing algorithm, and it=20
> keeps a good separation of concerns.
> =20
> - A ValidatorSource interface (very DAO like) which loads validators=20
> processed (and optionally cached) by ValidationService.  Source=20
> implementations can use commons attributes, programmatic builder-style =

> via Spring IoC or a scripting technology or by hand, a config file,=20
> whatever.
> =20
> Then, for the spring-rcp, where I need a richer results collector=20
> interface:
> --
> =20
> public interface RichClientValidationService {
>     public void validateBean(Object bean, ValidationResultsCollector=20
> results);
>     public void validatePropertyValue(Object bean, String =
propertyName,
>             Object value, ValidationResultsCollector results);
>     public void validatePropertyValues(Object bean, String[] =
properties,
>             Object[] values, ValidationResultsCollector results); }
> =20
> ... and of course I'll leverage a lot of the common classes between=20
> us...
> =20
> So you get a simple interface, backwards compatability, and I can=20
> extend it for the spring-rcp stuff.  Keith
> =20
> =20
>=20


sam
http://www.magpiebrain.com/



-------------------------------------------------------
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=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] declarative validation rules inte rfaces

[Kopylenko, D. <dko...@ac...>]

Yes, we could wait for Confluence (coming soon...) and collaborate there !

-----Original Message-----
From: sam...@ma... [mailto:sam...@ma...] 
Sent: Thursday, March 04, 2004 10:32 AM
To: spr...@li...
Subject: Re: [Springframework-developer] declarative validation rules
interfaces


Looks fantastic Keith. I guess I just have to write a simple
ValidationInterceptor to call the ValidationSource....with that in mind I've
posted a simple overview diagram showing how my commands get executed and
invoked at my blog here: http://www.magpiebrain.com/archives/000189.html. We
could do with a Wiki or website for this stuff perhaps - would make
documenting spring-rcp a little easier...

sam

Quoting Keith Donald <kd...@cs...>:

> How does this look -  I propose one interface you have to deal with to 
> the entire declarative validation subsystem.  Let me know what you 
> think:
>  
> public interface Validator {
>     public boolean supports(Class beanClass);
>     public void validate(Object bean, Errors errors);
> }
>  
> Look familiar? It's the existing spring Validator interface! We can 
> use it and have a ValidationService implementation that uses a 
> AttributesValidatorSource to load individual validators using 
> commons-attributes.
>  
> This provides:
>  
> - 100% backwards compatablility since the core interface is exactly 
> what we deal with now for 'programmatic' validators.
>  
> - A single implementation -- ValidationService -- that encapsulates 
> the workflow for invoking the various declarative validators and 
> collecting the results.  This implementation is independent of any 
> source of validation rules (like via attributes.)  This allows us to 
> vary the source without impacting the processing algorithm, and it 
> keeps a good separation of concerns.
>  
> - A ValidatorSource interface (very DAO like) which loads validators 
> processed (and optionally cached) by ValidationService.  Source 
> implementations can use commons attributes, programmatic builder-style 
> via Spring IoC or a scripting technology or by hand, a config file, 
> whatever.
>  
> Then, for the spring-rcp, where I need a richer results collector 
> interface:
> --
>  
> public interface RichClientValidationService {
>     public void validateBean(Object bean, ValidationResultsCollector 
> results);
>     public void validatePropertyValue(Object bean, String propertyName,
>             Object value, ValidationResultsCollector results);
>     public void validatePropertyValues(Object bean, String[] properties,
>             Object[] values, ValidationResultsCollector results); }
>  
> ... and of course I'll leverage a lot of the common classes between 
> us...
>  
> So you get a simple interface, backwards compatability, and I can 
> extend it for the spring-rcp stuff.  Keith
>  
>  
> 


sam
http://www.magpiebrain.com/



-------------------------------------------------------
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] declarative validation rules interfaces

[<sam...@ma...>]

Looks fantastic Keith. I guess I just have to write a simple
ValidationInterceptor to call the ValidationSource....with that in mind I've
posted a simple overview diagram showing how my commands get executed and
invoked at my blog here: http://www.magpiebrain.com/archives/000189.html. We
could do with a Wiki or website for this stuff perhaps - would make documenting
spring-rcp a little easier...

sam

Quoting Keith Donald <kd...@cs...>:

> How does this look -  I propose one interface you have to deal with to the
> entire declarative validation subsystem.  Let me know what you think:
>  
> public interface Validator {
>     public boolean supports(Class beanClass);
>     public void validate(Object bean, Errors errors);
> }
>  
> Look familiar? It's the existing spring Validator interface! We can use it
> and have a ValidationService implementation that uses a
> AttributesValidatorSource to load individual validators using
> commons-attributes.
>  
> This provides:
>  
> - 100% backwards compatablility since the core interface is exactly what we
> deal with now for 'programmatic' validators.
>  
> - A single implementation -- ValidationService -- that encapsulates the
> workflow for invoking the various declarative validators and collecting the
> results.  This implementation is independent of any source of validation
> rules (like via attributes.)  This allows us to vary the source without
> impacting the processing algorithm, and it keeps a good separation of
> concerns.
>  
> - A ValidatorSource interface (very DAO like) which loads validators
> processed (and optionally cached) by ValidationService.  Source
> implementations can use commons attributes, programmatic builder-style via
> Spring IoC or a scripting technology or by hand, a config file, whatever.
>  
> Then, for the spring-rcp, where I need a richer results collector interface:
> --
>  
> public interface RichClientValidationService {
>     public void validateBean(Object bean, ValidationResultsCollector
> results);
>     public void validatePropertyValue(Object bean, String propertyName,
>             Object value, ValidationResultsCollector results);
>     public void validatePropertyValues(Object bean, String[] properties,
>             Object[] values, ValidationResultsCollector results);
> }
>  
> ... and of course I'll leverage a lot of the common classes between us...
>  
> So you get a simple interface, backwards compatability, and I can extend it
> for the spring-rcp stuff.  Keith
>  
>  
> 


sam
http://www.magpiebrain.com/

[Springframework-developer] declarative validation rules interfaces

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

How does this look -  I propose one interface you have to deal with to =
the
entire declarative validation subsystem.  Let me know what you think:
=20
public interface Validator {
    public boolean supports(Class beanClass);
    public void validate(Object bean, Errors errors);
}
=20
Look familiar? It's the existing spring Validator interface! We can use =
it
and have a ValidationService implementation that uses a
AttributesValidatorSource to load individual validators using
commons-attributes.
=20
This provides:
=20
- 100% backwards compatablility since the core interface is exactly what =
we
deal with now for 'programmatic' validators.
=20
- A single implementation -- ValidationService -- that encapsulates the
workflow for invoking the various declarative validators and collecting =
the
results.  This implementation is independent of any source of validation
rules (like via attributes.)  This allows us to vary the source without
impacting the processing algorithm, and it keeps a good separation of
concerns.
=20
- A ValidatorSource interface (very DAO like) which loads validators
processed (and optionally cached) by ValidationService.  Source
implementations can use commons attributes, programmatic builder-style =
via
Spring IoC or a scripting technology or by hand, a config file, =
whatever.
=20
Then, for the spring-rcp, where I need a richer results collector =
interface:
--
=20
public interface RichClientValidationService {
    public void validateBean(Object bean, ValidationResultsCollector
results);
    public void validatePropertyValue(Object bean, String propertyName,
            Object value, ValidationResultsCollector results);
    public void validatePropertyValues(Object bean, String[] properties,
            Object[] values, ValidationResultsCollector results);
}
=20
... and of course I'll leverage a lot of the common classes between =
us...
=20
So you get a simple interface, backwards compatability, and I can extend =
it
for the spring-rcp stuff.  Keith
=20
=20

Re: [Springframework-developer] Release policy

[Mike Cannon-B. <mi...@at...>]

Love it - great ideas.

I don't really think the versioning number matters really, although 1.0.1
sounds more like a bugfix release to me than new features?

Cheers,
Mike

On 4/3/04 8:13 PM, "j=FCrgen h=F6ller [werk3AT]" (jue...@we...)
penned the words:

> Everybody,
>=20
> I'd like to propose a somewhat different release policy for post-1.0.
> Currently, we're targetting a major 1.1 release, with a M1 milestone as f=
irst
> goal. This doesn't seem very appropriate for getting features and add-ons=
 out
> early.
>=20
> When I look at the 1.1 roadmap in JIRA, almost all suggested features are
> add-ons that do not affect the Spring core. They could easily be added
> one-by-one as soon as they're stable. 1.0 users could still easily upgrad=
e
> without worrying: Such 1.x releases would be fully compatible, mainly add=
ing
> additional classes.
>=20
> OGNL support probably requires special consideration: However, if we adde=
d it
> via a FactoryBean implementation analogous to MethodInvokingFactoryBean, =
it
> would be a simple add-on too.
>=20
> So what I'd like to propose concretely is:
> - quick 1.x releases, getting out smaller sets of new features and add-on=
s
> early
> - no milestones for 1.x releases, just release candidates
> - CVS HEAD always contains the current 1.x codebase
> - bugfix releases like 1.0.x only when there's no compatible next release=
 like
> 1.1 available
> - 1.0.x/1.1.x/etc releases can also introduce minor new features if
> appropriate
> - major new features or add-ons force a jump to the next 1.x release numb=
er
> (1.0 -> 1.1)
>=20
> This essentially means that we do not stick to a release plan that's cast=
 in
> stone. Assuming that 1.0 final will be out in mid March, we'll simply wor=
k on
> some planned features: in the sandbox while not fully baked, moving to th=
e
> main source tree when something approaches release candidate status. Once=
 a
> noteworthy number of new features is there, we'll do a follow-up release:=
 in
> case of bugfixes and minor features, 1.0.1/1.0.2/etc; in case of one or m=
ore
> major features, 1.1/1.2/etc.
>=20
> My main intent is to get new features - that are ready and do not require
> signficant modifications to the Spring core - out promptly: When we finis=
h
> FreemarkerView, let's do 1.0.1; when we finish JMS support or any such ma=
jor
> feature (one or more), let's do 1.1. When e.g. JMX support gets done, we'=
ll do
> a follow-up 1.2; or the other way round, if JMX support gets ready first.=
 If
> there's pressure for a bugfix release, let's fit that in; it might also
> contain minor new features that are ready.
>=20
> If we decide to break compatibility (beyond trivial things in rather obsc=
ure
> places) at some time, we need to jump to the next major version, doing fu=
rther
> bugfixing for 1.x and such new development on a 2.0 branch in parallel - =
then
> and only then. I see no need to impose such burdens for add-on features i=
n 1.x
> releases, particularly when raising them in the sandbox before they join =
the
> mainstream.
>=20
> All things considered, the release policy that I propose is much more agi=
le
> than a fixed set of 1.1 features that will just make it into a final rele=
ase
> when all of them are ready. A large number of such fixed features could d=
elay
> a release for a long time. Note that significant changes to the Spring co=
re
> are a different matter; features that depend on such require special
> consideration. But for rather straightforward add-ons, we don't need to t=
ie
> ourselves to a strict release plan, IMO.
>=20
> In other words, let's adopt a Hibernate-style release policy, not a
> Jakarta-style one ;-) Eagerly awaiting your feedback!
>=20
> Regards,
> Juergen
>=20
>=20
>=20
> -------------------------------------------------------
> 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

[Springframework-developer] Spring command-driven framework

[<sam...@ma...>]

This might be a little too RCP specific, but I'd like to avail myself of the
knowledge here. As you may be aware I've been working on a spring-driven command
framework view a view to integrating it into the RCP project. Based originally
on my attempts to properly implement Spring into XWork, its a fairly simple
framework. You define Command objects in your applicationContext, then bundle
them all up as Proxies using a single BeanNameAutoProxyCreator (outlined here:
http://www.magpiebrain.com/archives/000187.html).
Anyway, I have a few design issues:

1.) Using a ValidatorRegistry and supporting ValidatorInterceptor, I can apply
validation rules to specific commands easily enough. The fact that I'm using a 
BeanNameAutoProxyCreator however opens the developer up to the danger that they
might forget to apply the ValidationInterceptor even if defined. Is the best I
can do to safeguard against this just to document it well?

2.) Ideally, I want to completely decouple GUI interaction from the Command into
an XWork-like Result object. The Command executes, and depending on the return
value the correct Result object gets executed. Again I'm thinking of using an
Interceptor to grab the result and execute it. Does this make sense to you? 

3.) So far, none of what I have done apart from the creation of a
SwingActionFactory (which creates javax.swing.Action classes to invoke Commands)
is actually dependent on the use of a rich client - it would as far as I can see
work equally well for a web interface. This is unsurprising given that much of
the design was inspired by XWork, which forms the basis for WebWork. Whilst the
focus of this project is certainly to support the RCP project, is it worth me
trying to keep the design abstract enough to support the use of web clients?

Anyway, I hope to have an example Swing GUI using the Command framework that
people can download and have a play with quite soon.

sam

Re: [Springframework-developer] RE: validation stuff

[<sam...@ma...>]

Quoting Keith Donald <kd...@cs...>:

> Another benefit of those abstractions is they make it easier for the
> validator be used in other contexts.  For example, maybe I want a
> ValidationInterceptor which can take any bean, look up its validator, and
> invoke the validation methods -- maybe as part of a command framework.  Or
> maybe I want to wrap a domain object in a AOP proxy that invokes a
> BeanValidator when set() methods are called.  Maybe I want validation rules
> to come from another source other than attributes metadata.  That's easier
> to do with the domain abstractions around than with the metadata stuff all
> coupled in with your validation processing logic...

The notion of being able to define a set of validator rules for a specific
command, then have a ValidatorInterceptor look them up is exactly what I need.
At present I'm trying to streamline the command declaration process in the (rcp)
command framework, and I really want to avoid having to have a proxy declaration
for each command.

sam
http://www.magpiebrain.com/

[Springframework-developer] Release policy

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

Everybody,
=20
I'd like to propose a somewhat different release policy for post-1.0. =
Currently, we're targetting a major 1.1 release, with a M1 milestone as =
first goal. This doesn't seem very appropriate for getting features and =
add-ons out early.
=20
When I look at the 1.1 roadmap in JIRA, almost all suggested features =
are add-ons that do not affect the Spring core. They could easily be =
added one-by-one as soon as they're stable. 1.0 users could still easily =
upgrade without worrying: Such 1.x releases would be fully compatible, =
mainly adding additional classes.
=20
OGNL support probably requires special consideration: However, if we =
added it via a FactoryBean implementation analogous to =
MethodInvokingFactoryBean, it would be a simple add-on too.
=20
So what I'd like to propose concretely is:
- quick 1.x releases, getting out smaller sets of new features and =
add-ons early
- no milestones for 1.x releases, just release candidates
- CVS HEAD always contains the current 1.x codebase
- bugfix releases like 1.0.x only when there's no compatible next =
release like 1.1 available
- 1.0.x/1.1.x/etc releases can also introduce minor new features if =
appropriate
- major new features or add-ons force a jump to the next 1.x release =
number (1.0 -> 1.1)
=20
This essentially means that we do not stick to a release plan that's =
cast in stone. Assuming that 1.0 final will be out in mid March, we'll =
simply work on some planned features: in the sandbox while not fully =
baked, moving to the main source tree when something approaches release =
candidate status. Once a noteworthy number of new features is there, =
we'll do a follow-up release: in case of bugfixes and minor features, =
1.0.1/1.0.2/etc; in case of one or more major features, 1.1/1.2/etc.
=20
My main intent is to get new features - that are ready and do not =
require signficant modifications to the Spring core - out promptly: When =
we finish FreemarkerView, let's do 1.0.1; when we finish JMS support or =
any such major feature (one or more), let's do 1.1. When e.g. JMX =
support gets done, we'll do a follow-up 1.2; or the other way round, if =
JMX support gets ready first. If there's pressure for a bugfix release, =
let's fit that in; it might also contain minor new features that are =
ready.
=20
If we decide to break compatibility (beyond trivial things in rather =
obscure places) at some time, we need to jump to the next major version, =
doing further bugfixing for 1.x and such new development on a 2.0 branch =
in parallel - then and only then. I see no need to impose such burdens =
for add-on features in 1.x releases, particularly when raising them in =
the sandbox before they join the mainstream.
=20
All things considered, the release policy that I propose is much more =
agile than a fixed set of 1.1 features that will just make it into a =
final release when all of them are ready. A large number of such fixed =
features could delay a release for a long time. Note that significant =
changes to the Spring core are a different matter; features that depend =
on such require special consideration. But for rather straightforward =
add-ons, we don't need to tie ourselves to a strict release plan, IMO.
=20
In other words, let's adopt a Hibernate-style release policy, not a =
Jakarta-style one ;-) Eagerly awaiting your feedback!
=20
Regards,
Juergen
=20

RE: [Springframework-developer] How to provide a singleton instance as a bean in spring

[Cameron B. <ca...@da...>]

Excellent.. Thanks.

Cameron=20

> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of j=FCrgen h=F6ller [werk3AT]
> Sent: Thursday, 4 March 2004 6:04 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] How to provide a=20
> singleton instance as a bean in spring
>=20
> There indeed is:
> =20
> <bean name=3D"MyRegistry"=20
> class=3D"org.springframework.beans.factory.config.MethodInvoking
> FactoryBean">
>     <propety=20
> name=3D"staticMethod"><value>com.datacodex.MyRegistry.getInstanc
> e</value></property>
> </bean>
> =20
> Method arguments would have to be specified as "arguments"=20
> property (an Object array).
> =20
> Juergen
> =20
>=20
> ________________________________
>=20
> Von: spr...@li... im=20
> Auftrag von Cameron Braid
> Gesendet: Do 04.03.2004 08:54
> An: spr...@li...
> Betreff: [Springframework-developer] How to provide a=20
> singleton instance as a bean in spring
>=20
>=20
> Is there an existing bean factory implementation that allows=20
> me to expose any bean that uses the singleton pattern to my=20
> application context ?
> =20
> For example I would like to do something like this :
> =20
> <bean name=3D"MyRegistry" class=3D"singletonFactoryBean">
>     <propety=20
> name=3D"signiture"><value>com.datacodex.MyRegistry.getInstance()
> </value></property>
> </bean>
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials Free=20
> Linux tutorial presented by Daniel Robbins, President and CEO=20
> of GenToo technologies. Learn everything from fundamentals to=20
> 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
>=20
>=20

Re: [Springframework-developer] How to provide a singleton instance as a bean in spring

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

There indeed is:
=20
<bean name=3D"MyRegistry" =
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
    <propety =
name=3D"staticMethod"><value>com.datacodex.MyRegistry.getInstance</value>=
</property>
</bean>
=20
Method arguments would have to be specified as "arguments" property (an =
Object array).
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Cameron Braid
Gesendet: Do 04.03.2004 08:54
An: spr...@li...
Betreff: [Springframework-developer] How to provide a singleton instance =
as a bean in spring


Is there an existing bean factory implementation that allows me to =
expose any bean that uses the singleton pattern to my application =
context ?
=20
For example I would like to do something like this :
=20
<bean name=3D"MyRegistry" class=3D"singletonFactoryBean">
    <propety =
name=3D"signiture"><value>com.datacodex.MyRegistry.getInstance()</value><=
/property>
</bean>

[Springframework-developer] How to provide a singleton instance as a bean in spring

[Cameron B. <ca...@da...>]

Is there an existing bean factory implementation that allows me to expose
any bean that uses the singleton pattern to my application context ?
 
For example I would like to do something like this :
 
<bean name="MyRegistry" class="singletonFactoryBean">
    <propety
name="signiture"><value>com.datacodex.MyRegistry.getInstance()</value></prop
erty>
</bean>
 

Re: [Springframework-developer] RE: validation stuff

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

Seth,

Those abstractions I'm talking about actually do make the code simpler and
decouple the validation processing with the metadata (configuration) API.
Furthermore, they form the basis for the cache I'm talking about.  They
introduce a few new interfaces yet, but they're simple interfaces.  And you
don't have to deal with them, as I mentioned in my last email - your
interface is exactly the same (aside from our two classname differences.)

Another benefit of those abstractions is they make it easier for the
validator be used in other contexts.  For example, maybe I want a
ValidationInterceptor which can take any bean, look up its validator, and
invoke the validation methods -- maybe as part of a command framework.  Or
maybe I want to wrap a domain object in a AOP proxy that invokes a
BeanValidator when set() methods are called.  Maybe I want validation rules
to come from another source other than attributes metadata.  That's easier
to do with the domain abstractions around than with the metadata stuff all
coupled in with your validation processing logic...

I agree completely we should use Errors.  What I would like to do is take
the best parts of your design and take the parts of mine I feel are strong
and merge the two in the sandbox for review.  Nothings going to be
complicated, hopefully simplified.  If something doesn't meet your
requirements, let me know immediately!  I'll work with you to get our stuff
committed ASAP.

Keith

----- Original Message ----- 
From: "Seth Ladd" <se...@eh...>
To: <spr...@li...>
Sent: Wednesday, March 03, 2004 8:16 PM
Subject: Re: [Springframework-developer] RE: validation stuff


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> | Do you prefer 'explicit' (beforehand) configuration of the validateable
> | classes via the metadata API or do you think it is better for that to
> happen
> | lazily/implicity when the registry validate(command, results) method is
> | invoked?  In the latter case, we would cache the
> | BeanValidator/PropertyValidator references in the registry once we
derive
> | them from the source-metadata resulting in better performance.
>
>
> That is a great idea.  AttributeValidator should cache the validation
> rules it finds for each command class.  Since AttributeValidator will
> usually be used as a singleton, this might help and cut down on the
> reflection and attribute discovery.
>
> Hopefully I'll be allowed to checkin the current Attribute Validator and
> we can start flushing it out.  I'm not sure what we gain from all those
> levels of abstraction you have proposed.  One of the nice things I like
> about the current attribute validator is that it doesn't introduce any
> new classes or interfaces; it tries to remain small and simple.
>
> But again, maybe those abstractions should remain only in the RCP
> project.  Once they've proved themselves as useful to a more general
> validation API (the current Spring one) we can integrate them.  I'm not
> anti-abstractions, I just haven't seen the need for them (yet).
>
> I don't want to lose the Errors interface from the validation API.  It's
> integrated into Spring already and other APIs (like the JSP tags)
> already work with it.
>
> Seth
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFARoNc5EIB1scRes8RAlNDAJ4h0aewSC4PGm8F06VBnvzFJ5u+4QCeOIMD
> FLOsi9/0fHkUAESpEbY+3Cc=
> =3/Qn
> -----END PGP SIGNATURE-----
>
>
>
> -------------------------------------------------------
> 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: validation stuff

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


| Do you prefer 'explicit' (beforehand) configuration of the validateable
| classes via the metadata API or do you think it is better for that to
happen
| lazily/implicity when the registry validate(command, results) method is
| invoked?  In the latter case, we would cache the
| BeanValidator/PropertyValidator references in the registry once we derive
| them from the source-metadata resulting in better performance.


That is a great idea.  AttributeValidator should cache the validation
rules it finds for each command class.  Since AttributeValidator will
usually be used as a singleton, this might help and cut down on the
reflection and attribute discovery.

Hopefully I'll be allowed to checkin the current Attribute Validator and
we can start flushing it out.  I'm not sure what we gain from all those
levels of abstraction you have proposed.  One of the nice things I like
about the current attribute validator is that it doesn't introduce any
new classes or interfaces; it tries to remain small and simple.

But again, maybe those abstractions should remain only in the RCP
project.  Once they've proved themselves as useful to a more general
validation API (the current Spring one) we can integrate them.  I'm not
anti-abstractions, I just haven't seen the need for them (yet).

I don't want to lose the Errors interface from the validation API.  It's
integrated into Spring already and other APIs (like the JSP tags)
already work with it.

Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFARoNc5EIB1scRes8RAlNDAJ4h0aewSC4PGm8F06VBnvzFJ5u+4QCeOIMD
FLOsi9/0fHkUAESpEbY+3Cc=
=3/Qn
-----END PGP SIGNATURE-----

[Springframework-developer] RE: validation stuff

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

I think we're nearing agreement.  Your 'AttributesValidator' is =
analagous to
my 'ValidatorRegistry', except your class has the capability to kick off
validation for any command/bean, which is a great idea.

This is what I'm proposing:

1. The user creates source-level-metadata describing property validation
rules for their various bean classes.

2. Using the spring metadata API, the system auto-generates
BeanValidator/PropertyValidator instances (the API we've been discussing
with the good abstractions) for each validateable class.  So you know =
for
each bean which properties are to be validated, and which validation =
rules
apply (and there is nice model for this.)

	Note: this step could require some Spring configuration to specify
which validateable classes to introspect using the metadata API (or we =
could
do it like you do it, which is lazily introspect every command...either =
way
works for me...one is more explicit, the other is more flexible.)

3. Once the BeanValidator models are created, individual BeanValidators =
are
added to the ValidatorRegistry (we might need a better name than
'registry'.) (again this may happen in reverse if we go with on-demand
'validation-rule discovery' like you do now.)

4. The ValidatorRegistry is bound to each controller needing to validate
commands.  It provides a one stop shop for validating any bean.

5. Each controller simply calls 'registry.validate(command, results)', =
and
it kicks the validation process off, returning localized results =
messages.
The algorithm will proceed down through any object graph and validate =
nested
beans (this opens up some issues: what if a nested bean property is =
null?)
I can improve performance on this by having separate BeanValidators
generated for each bean class, and then link them for the algorithm to
traverse...)  I can create a Errors adapter for the
ValidationResultsCollector interface, since Errors is supported with jsp
tags for rendering, right?

Is that acceptable? Did I miss anything? =20

Do you prefer 'explicit' (beforehand) configuration of the validateable
classes via the metadata API or do you think it is better for that to =
happen
lazily/implicity when the registry validate(command, results) method is
invoked?  In the latter case, we would cache the
BeanValidator/PropertyValidator references in the registry once we =
derive
them from the source-metadata resulting in better performance.

Keith



-----Original Message-----
From: Seth Ladd [mailto:se...@eh...]=20
Sent: Wednesday, March 03, 2004 6:30 PM
To: Keith Donald; spr...@li...
Subject: Re: validation stuff


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(putting this reply on list because of some explanation that might =
others)

Keith Donald wrote:
| Seth,
|
| The way I look at it is this:
|
| The validation rules I want to apply to a domain object are generally=20
| very specific to that domain object.  For example, I may have a Pet=20
| class, like in the Pet clinic.  I want to validate that all Pet's have =

| a name, all
Pet's
| have a unique name, and no Pet weighs less than 1 pound.  I can either


Yes, this is exactly the way Spring works now.  It asks you to bind a
certain validator to a certain controller class.

The way my Attribute Validator works, is you place the validation =
attributes
on the domain object.  This way, the domain object has the validation =
meta
data attached to it.  All you need to bind is the generic =
AttributeValidator
class to each controller.  This way, one validator handles all domain
objects (as long as they have the validation rules bound to them, of =
course
:)

More and more it sounds like we're coming from two opposite ends.  No =
right
or wrong here, just very different.


| Or I can just go to my Pet.java source file and see them as=20
| source-level attributes.

Right, this is exactly what I do.  No need for a resolver now.



| commons-attributes?  However, that still doesn't cut out the need to
lookup
| the validator for a bean (aka command in spring-web) in order to kick


See above and my code.  I should put an example on the web site I put =
up.
That might explain everything.


General Explanation:

1 (singleton) AttributeValidator for webapp, implements spring.Validator =
N
controllers N command objects (the beans populated from the form)

1:1 controller:command object
1:1 controller:validator

1:M command object:attributes (validation rules)

So the command object has the validation rules in form of attributes. =
The
generic attributevalidator can look into the command object, get the
attributes, and do the validation.

Hope that helps.
Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFARmpg5EIB1scRes8RAuGyAJ9VTMEJ8u8Ss+Vj/RtVvWwzyhpJ+ACePtgr
HnkBdQsJSdJTWCrBQxsjUh8=3D
=3D0TbM
-----END PGP SIGNATURE-----

Re: [Springframework-developer] Poll

[Mike Cannon-B. <mi...@at...>]

Good to be ahead, but seriously =AD this is a complete bullshit poll :)

How can you compare Hibernate (an ORM framework), with Spring (a
framework-framework), with JDK Generics (a language feature), with bluetoot=
h
(a networking protocol) - wtf?

M

On 4/3/04 12:40 AM, "Dmitriy Kopylenko" (dko...@ru...) penned the
words:

> Clear leaders here :
> http://www.manageability.org/polls/the-hottest-java-based-technology
> <http://www.manageability.org/polls/the-hottest-java-based-technology>  w=
ith
> Hibernate just a little behind :-)))
>=20
> Dmitriy.=20
>=20

[Springframework-developer] Re: validation stuff

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(putting this reply on list because of some explanation that might others)

Keith Donald wrote:
| Seth,
|
| The way I look at it is this:
|
| The validation rules I want to apply to a domain object are generally very
| specific to that domain object.  For example, I may have a Pet class, like
| in the Pet clinic.  I want to validate that all Pet's have a name, all
Pet's
| have a unique name, and no Pet weighs less than 1 pound.  I can either


Yes, this is exactly the way Spring works now.  It asks you to bind a
certain validator to a certain controller class.

The way my Attribute Validator works, is you place the validation
attributes on the domain object.  This way, the domain object has the
validation meta data attached to it.  All you need to bind is the
generic AttributeValidator class to each controller.  This way, one
validator handles all domain objects (as long as they have the
validation rules bound to them, of course :)

More and more it sounds like we're coming from two opposite ends.  No
right or wrong here, just very different.


| Or I can just go to my Pet.java source file and see them as source-level
| attributes.

Right, this is exactly what I do.  No need for a resolver now.



| commons-attributes?  However, that still doesn't cut out the need to
lookup
| the validator for a bean (aka command in spring-web) in order to kick


See above and my code.  I should put an example on the web site I put
up.  That might explain everything.


General Explanation:

1 (singleton) AttributeValidator for webapp, implements spring.Validator
N controllers
N command objects (the beans populated from the form)

1:1 controller:command object
1:1 controller:validator

1:M command object:attributes (validation rules)

So the command object has the validation rules in form of attributes.
The generic attributevalidator can look into the command object, get the
attributes, and do the validation.

Hope that helps.
Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFARmpg5EIB1scRes8RAuGyAJ9VTMEJ8u8Ss+Vj/RtVvWwzyhpJ+ACePtgr
HnkBdQsJSdJTWCrBQxsjUh8=
=0TbM
-----END PGP SIGNATURE-----

RE: RE: [Springframework-developer] Lifecycle methods

[James C. <jim...@do...>]

FWIW, I added the depends-on to my bean along with the init-method.

The init-method still fires prior to the "depends-on" bean getting all of
its properties set.

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Dmitriy Kopylenko
> 
> Yes, I know what you mean, but I'm not sure how to deal with this
> situation. Will <bean id="BEAN_NOT_DAO" class="whatever" depends-
> on="BEAN_DAO"> work in this kind of a situation? Anyone?

RE: RE: [Springframework-developer] Lifecycle methods

[<tri...@tr...>]

James,

Have you tried implementing an ApplicationListener interface in your
BEAN_NOT_DAO.  I've never used it but it sounds like it could solve your
problem.  Look at section 3.10.2 in the reference manual.

Thomas


Quoting James Cook <jim...@do...>:

> I think we are both on the same page, but you have to go back to my initial
> post to see the problem. I have two singleton beans that point at each
> other. One is a DAO (BEAN_DAO) and the other is not (BEAN_NOT_DAO). The
> problem is that I need to initialize BEAN_NOT_DAO once the factory has set
> all of the properties on *both* beans. This is because BEAN_NOT_DAO depends
> on a call to BEAN_DAO that requires the setSessionFactory(HibernateSession)
> call to be made already.
> 
> Unfortunately, there does not seem to be a hook provided by the BeanFactory
> to configure objects after all there dependencies are resolved.
> 
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behalf
> > Of Kopylenko, Dmitry
> > Nope, this is exactly what the BeanFactoryPostProcessor is all about - no
> > bean instances has been created yet, but all RootBeanDefinitions has been
> > "prepared".
> > 
> > What do you mean it's still too early?
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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: RE: RE: [Springframework-developer] Lifecycle methods

[Dmitriy K. <dko...@ru...>]

Yes, I know what you mean, but I'm not sure how to deal with this situation. Will <bean id="BEAN_NOT_DAO" class="whatever" depends-on="BEAN_DAO"> work in this kind of a situation? Anyone?

----- Original Message -----
From: James Cook <jim...@do...>
Date: Wednesday, March 3, 2004 5:02 pm
Subject: RE: RE: [Springframework-developer] Lifecycle methods

> I think we are both on the same page, but you have to go back to 
> my initial
> post to see the problem. I have two singleton beans that point at each
> other. One is a DAO (BEAN_DAO) and the other is not 
> (BEAN_NOT_DAO). The
> problem is that I need to initialize BEAN_NOT_DAO once the factory 
> has set
> all of the properties on *both* beans. This is because 
> BEAN_NOT_DAO depends
> on a call to BEAN_DAO that requires the 
> setSessionFactory(HibernateSession)call to be made already.
> 
> Unfortunately, there does not seem to be a hook provided by the 
> BeanFactoryto configure objects after all there dependencies are 
> resolved.
> > -----Original Message-----
> > From: spr...@li...
> > [spr...@li...] On Behalf
> > Of Kopylenko, Dmitry
> > Nope, this is exactly what the BeanFactoryPostProcessor is all 
> about - no
> > bean instances has been created yet, but all RootBeanDefinitions 
> has been
> > "prepared".
> > 
> > What do you mean it's still too early?
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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: RE: [Springframework-developer] Lifecycle methods

[James C. <jim...@do...>]

I think we are both on the same page, but you have to go back to my initial
post to see the problem. I have two singleton beans that point at each
other. One is a DAO (BEAN_DAO) and the other is not (BEAN_NOT_DAO). The
problem is that I need to initialize BEAN_NOT_DAO once the factory has set
all of the properties on *both* beans. This is because BEAN_NOT_DAO depends
on a call to BEAN_DAO that requires the setSessionFactory(HibernateSession)
call to be made already.

Unfortunately, there does not seem to be a hook provided by the BeanFactory
to configure objects after all there dependencies are resolved.

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Kopylenko, Dmitry
> Nope, this is exactly what the BeanFactoryPostProcessor is all about - no
> bean instances has been created yet, but all RootBeanDefinitions has been
> "prepared".
> 
> What do you mean it's still too early?

RE: RE: [Springframework-developer] Lifecycle methods

[Kopylenko, D. <dko...@ac...>]

Nope, this is exactly what the BeanFactoryPostProcessor is all about - no
bean instances has been created yet, but all RootBeanDefinitions has been
"prepared".

What do you mean it's still too early?

-----Original Message-----
From: James Cook [mailto:jim...@do...] 
Sent: Wednesday, March 03, 2004 4:29 PM
To: spr...@li...
Subject: RE: RE: [Springframework-developer] Lifecycle methods


Well, the getBean("") call is done by the BeanFactory because these are
singleton beans. After the bean in instanced is when the
postProcessBeanFactory() method is invoked.

Even then, it is still too early. I think we need an interface that any bean
can implement that fires after the BeanFactory completes its configuration.
Something like:

public interface postBeanFactoryConfigure {
	void postConfigureBeanFactory(BeanFactory beanFactory);
}

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of Kopylenko, Dmitry
> Sent: Wednesday, March 03, 2004 3:44 PM
> To: 'spr...@li...'
> Subject: RE: RE: [Springframework-developer] Lifecycle methods
> 
> I would think by doing something like this:
> 
> postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
> 	beanFactory.getBean("beanName");
> }
> 
> it would instantiate the bean, if not done so already and call its 
> lifecycle callbacks
> 
> Juergen, can you confirm, please.
> 
> -----Original Message-----
> From: James Cook [mailto:jim...@do...]
> Sent: Wednesday, March 03, 2004 1:56 PM
> To: spr...@li...
> Subject: RE: RE: [Springframework-developer] Lifecycle methods
> 
> 
> Thanks, but in relation to my original request, how can I invoke a 
> method on my singleton bean only after all other beans have been 
> created by the factory? Does this capability exist?
> 
> How are others handling a cyclic redundancy between two beans?
> 
> > -----Original Message----- 
> > [mailto:spr...@li...] On 
> > Behalf Of Kopylenko, Dmitry Yes, this is the correct behavior of the 
> > BeanFactoryPostProcessor.
> > postProcessBeanFactory() gets called when all bean definitions will 
> > have been loaded, but no beans will have been instantiated yet.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and 
> deploy apps & Web services for Linux with a free DVD software kit from 
> IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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: RE: [Springframework-developer] Lifecycle methods

[James C. <jim...@do...>]

Well, the getBean("") call is done by the BeanFactory because these are
singleton beans. After the bean in instanced is when the
postProcessBeanFactory() method is invoked.

Even then, it is still too early. I think we need an interface that any bean
can implement that fires after the BeanFactory completes its configuration.
Something like:

public interface postBeanFactoryConfigure {
	void postConfigureBeanFactory(BeanFactory beanFactory);
}

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Kopylenko, Dmitry
> Sent: Wednesday, March 03, 2004 3:44 PM
> To: 'spr...@li...'
> Subject: RE: RE: [Springframework-developer] Lifecycle methods
> 
> I would think by doing something like this:
> 
> postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
> 	beanFactory.getBean("beanName");
> }
> 
> it would instantiate the bean, if not done so already and call its
> lifecycle
> callbacks
> 
> Juergen, can you confirm, please.
> 
> -----Original Message-----
> From: James Cook [mailto:jim...@do...]
> Sent: Wednesday, March 03, 2004 1:56 PM
> To: spr...@li...
> Subject: RE: RE: [Springframework-developer] Lifecycle methods
> 
> 
> Thanks, but in relation to my original request, how can I invoke a method
> on
> my singleton bean only after all other beans have been created by the
> factory? Does this capability exist?
> 
> How are others handling a cyclic redundancy between two beans?
> 
> > -----Original Message-----
> > [mailto:spr...@li...] On
> > Behalf Of Kopylenko, Dmitry Yes, this is the correct behavior of the
> > BeanFactoryPostProcessor.
> > postProcessBeanFactory() gets called when all bean definitions will
> > have been loaded, but no beans will have been instantiated yet.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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: RE: [Springframework-developer] Lifecycle methods

[Kopylenko, D. <dko...@ac...>]

I would think by doing something like this:

postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
	beanFactory.getBean("beanName");
}

it would instantiate the bean, if not done so already and call its lifecycle
callbacks

Juergen, can you confirm, please.

-----Original Message-----
From: James Cook [mailto:jim...@do...] 
Sent: Wednesday, March 03, 2004 1:56 PM
To: spr...@li...
Subject: RE: RE: [Springframework-developer] Lifecycle methods


Thanks, but in relation to my original request, how can I invoke a method on
my singleton bean only after all other beans have been created by the
factory? Does this capability exist?

How are others handling a cyclic redundancy between two beans?

> -----Original Message----- 
> [mailto:spr...@li...] On 
> Behalf Of Kopylenko, Dmitry Yes, this is the correct behavior of the 
> BeanFactoryPostProcessor.
> postProcessBeanFactory() gets called when all bean definitions will 
> have been loaded, but no beans will have been instantiated yet.





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Request for Sandbox Inclusion

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Keith Donald wrote:
| Seth and I have similar but slightly different efforts ongoing between us.
| So it would silly for me to commit stuff that looks like his but not
quite.
| Personally I'd like one solution that works in both web and rcp
environments
| equally well.

While I believe that there can be a definite common base functionality
both can share, there are some issues that we might run into if all the
code was the same.  The major difference I can see is that a RCP
interface is /much/ different than a web interface.  With a RCP
interface, you're able to interact and provide feedback in much better
and faster ways than with a standard web client.  Of course, with a lot
of Javascript you can emulate a decent RCP interface experience.  Maybe
that's where this is heading.

But in the meantime, I can foresee that we share a lot of common
functionality, with the RCP specific code extending and enhancing it to
take advantage of the user experience improvements you can provide.

Also, time will tell on this.  We'll let the design emerge.


| before it is set on a domain object, which is important for me.  For
| example, Seth's validationRule interface looks like
|
| 	public boolean validate(Object object, Object field);
| <mine looks like>
| 	public boolean validate(Object object, Object value);


I think I am going to change this interface a bit, though not to match
yours.  Currently, the object is the object w/ the field.  I think the
object will become the top level object being validated.  This will
allow validation rules to validate against any field in the object
graph, instead of just a direct sibling field.


|
| The interfaces mean two different things conceptually.  My
| "MandatoryPropertyValidationRule" just looks at the value to enforce the
| not-null and not-empty constraint.  Other, more complex, rules might
use the
| object as a context to evaluate a proposed value (for example, a proposed
| value must be > then some existing value on the domain object.)

Not sure I understand what this is to do.  Can you provide an example?


| 2. Our ways of collecting results are a bit different.  I have
| ValidationResultsCollector interface, and Seth uses the Errors interface.
| Not a big deal, but the ValidationResultsCollector provides some
additional
| callbacks for tracking validation progress (starting, ending, etc.)
which I
| use to update a panel on a rich-client form.

This is where we see the web interface and the RCP interface start to
diverge.  This is also a good example of how the RCP can use the common
functionality and extend it at choice locations, such as extending the
Errors interface.  Do you extend Errors or bypass it completely?

|
| 3. I provide a programmatic interface for creating a BeanValidator which
| encapsulates one or more PropertyValidators which encapsulate one or more
| PropertyValidationRules.  Granted, with attributes you probably don't need
| this all the time, but it's still nice to have.

I guess nothing stops you from overriding onBindAndValidate method to
introduce new ValidationRules, or code some by hand.  So while there
isn't an explicit hook to dynamically generate the rules, it's
definitely easy to do so.

|
| 4. You retrieve an instance of the appropriate BeanValidator for a domain
| object by using the ValidatorRegistry, which indexes validators by domain
| object type.  Seth, one question I have is how do you bind a
| AttributeValidator instance to the correct domain object?

Not sure I quite understand this one.  The ValidationRule is generic in
that it doesn't care which object it's validating.  You merely associate
a validation rule to a getter on an object.  There is no declaring a
class itself is Validatable.  To get a class to be validated, you only
need to declare a validation rule on at least one getter.
Commons-attributes takes care of the rest.  Can you elaborate your question?

|
| 5. My rules encapsulate the message creation logic as well as 'typing
hint'
| creation logic since they own errorCode and rule messageArguments
data, but
| that's just a minor thing.

My validation rules also (optionally) provide all the message
parameters, but rely on MessageSource from Spring to actually generate
the message String.  Sounds like we are identical here.

I think we have more in common than not.  I tried really hard to stick
w/ current Spring classes and interfaces to make the impact of this
minimal.  I had to patch Spring a little tiny bit, which actually should
help your code out, too.

Choices never hurt, and I don't care if we delete all my code, as long
as there is a good attributes based validator in there.  I need it to
convince the team to move from Struts. :)

Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFARkKS5EIB1scRes8RAnsgAJ9xH3DNGWdpu8xJmGhmEU7wHK408gCfVdJG
XnMoV78NSJwtbgMt1+jVMB8=
=wrGa
-----END PGP SIGNATURE-----

RE: [Springframework-developer] Request for Sandbox Inclusion

[Mark P. <mar...@co...>]

+1, definitely.

Mark


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Alef Arendsen
Sent: Wednesday, March 03, 2004 1:43 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Request for Sandbox Inclusion


+1

I think validation based on attributes is a good addition to Spring.

Alef

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of Seth Ladd
> Sent: Wednesday, March 03, 2004 7:17 PM
> To: spr...@li...
> Subject: [Springframework-developer] Request for Sandbox Inclusion
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> Forgive me if I'm going at this the wrong way.  Please let me know if 
> there is another process I should follow.
> 
> I'd like to request that the Attribute Validator be included in the 
> Sandbox.  I'd like to continue work on it in a more public setting.  
> Our resources here at work aren't set up for hosting a public project.

> Also, it's my hope that the Attribute Validator will become a 
> supported option for validation in the spring framework (after much 
> testing!).
> 
> I believe others would find this project useful.  I will continue to 
> develop this library, as it has become core to our internal project.
> 
> Please let me know what other steps I should take before we could move

> it into the public sandbox.
> 
> Thanks very much, and thanks for Spring!
> Seth
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFARiEZ5EIB1scRes8RAkjRAJ0QWDCs/lhLXq8yZZpjKRoNVx3nUACdGUcb
> 3jCeT/hBEMOXGcL9ri+H274=
> =VrTA
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and 
> deploy apps & Web services for Linux with a free DVD software kit from

> IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer