For example, the new DateValidator looks like this:
public boolean isValid(Object bean, Field field); public boolean isValid(Object bean, Field field, Locale locale); public boolean isValid(String value, String datePattern, boolean strict); public boolean isValid(String value, Locale locale);
The top two methods do four things:
1. Pull the necessary parameters out of field variables (ie "datePattern" out of a field var to be passed to the third method)
2. Extract the field value as a String
3. Return true if the value is blank or null since the field may not be required (the bottom two methods return false in such a case)
4. Delegate handling to the bottom two methods
Any objections?
Don
David Graham wrote:
I'd be interested in any patches in this area so please open a bugzilla ticket for this. It sounds like you have some good ideas for making validator easier to use; I just don't have much time right now to look into it more.
Thanks, David
--- Don Brown <[EMAIL PROTECTED]> wrote:
After looking through the different validator usages - Struts, Spring, and the unit tests - I'm a bit confused why commons-validator doesn't ship with functional validators that can be used directly and not hidden
by some adapter. commons-validator contains validator classes, yes, but
you still need to create a validator adapter class that accepts at least
the bean and the Field object to interact with the validator. Furthermore, this adapter class (Struts and Spring both call it CheckFields) contains framework specific references, usually dealing with their errors system.
The problem with this approach is it requires huge levels of duplication
as each container needs to write their own adapter and error creation code. I'm particularly confused because it seems the solution already exists within commons-validator - ValidationResult(s). I would think a better approach would be for commons-validator to provide adapters for every validator to extract the field information from Field and pass it along to the actual validator. The process of creating messages should be left to the class that called validator.validate() to process ValidationResults and handle the errors in a container-specific way. This way, new containers that want to use commons-validator don't have to write their own monolithic adapter class but can use validators as they are. If commons-validator wants to separate a validator into a commons-validator adapter class and a actual validation class, that is fine, but there really isn't any need for that adapter to depend on a container.
If my premise is sound and the solution agreeable, I would be willing to
do the leg work of writing container-independent adapters for each of the validators.
Don
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
