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