RE: [Springframework-developer] purpose of code in Errors.rejectV alue()

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

Tony, John,

<quote>
To be honest, I'm not as familar with the Validator pattern. =20
From my recollection of that chapter in the book, I thought
Rod advocated having a separate object that contained all validation =
logic that both
the Business Object layer, and the Controller could call.  Better to =
have Rod
field that question.

[John Cavacas] That was my understanding as well in regards to the =
validator interface from reading the book. But unless I missed something =
obvious, I just don't see how that would work, especially from the =
Business Object layer side of things. I've been playing around with some =
ideas as well to come up with a way to have common "validator plug-ins". =
I saw a class in spring that I think is ment for that purpose, but it =
looks like an unfinished thought. I think that using the bean framework =
and maybe a change in the validator interface, could make that concept a =
reality, and it's something that I want to explore.
</quote>

Spring's validator framework is definitely meant to be reusable across =
presentation and business logic layers. This is a major USP compared to =
Struts' web-centric validation support.

You can define validator beans in your application context, e.g. a =
"userValidator" bean that implements =
com.interface21.validation.Validator and supports your User class. The =
bean definition can configure the validator via its properties. You can =
assign this bean to respective CommandController/FormController =
implementations as "validator" bean reference easily, for web controller =
validation. This is shown in chapter 12 of Rod's book.

Beyond usage in web controllers, you can assign your validator bean to =
any business logic services too, easily via bean reference if your =
services are registered as beans in your application context. For =
services outside of the application context, you could assign the =
validator bean manually by getting a reference to the application =
context, looking up the bean, and setting it to your service instance. =
All of this would work in a standalone application too, if it utilizes a =
Spring application Context.=20

Therefore, I don't see a need for validator plug-ins or the like. This =
demonstrates the power of the bean factory concept: You can achieve so =
much with it so easily.

BTW, I assume that the unfinished class in Spring's validation package =
that you mentioned is ValidationUtils. This class is meant to be a =
simple static utility class that provides low-level validation checks to =
ease Validator implementations. Don't confuse this with your Validator =
implementations and their reusability across multiple layers.

Regards,
Juergen