As for the context idea, I agree, that would be a nice way to not only pass in objects, but return more than true or false. In particular, I was needing the ability to pass in parameters that were simple strings to be used by different validators. Using the current design, that isn't possible. The only problem I see is the temptation to mix presentation classes like HttpServletRequest in the validation method, like how Struts' FieldChecks works now. There is value in forcing the validator to be written without knowledge of the context in which it is used.
Don
Niall Pemberton wrote:
Personally I prefer the "facade" method. I like the fact that, for example, the UrlValidator only contains the logic to validate a url and knows nothing about the "validator" framework it sits in. I think this has two advantages:
* Users could utilise the validation without having to adopt the framework - maybe embedding it in their "business logic" or an alternative framework. Some users (e.g. Edgar Dollin's recent message on the Struts Dev list) don't want to put their validation rules in an XML file. I don't think we should limit validator's use by forcing the adoption of the framework.
* It's easier to test - writing test scripts is simpler, you don't have to have a whole load of XML set up to test the actual validation logic.
The other thing I was thinking is that the method signitures are too simple...validations could return several things: true/false, a converted value, an error code, an error message - maybe all of these should be returned in a ValidatorResult object rather than just true/false. Also how about having a validator "context" object - in the Struts world if someone wanted to write a validator which accessed the Request, then they could provide it through the "context.
public ValidatorResult isValid(Object bean, Field field, ValidatorAction va, Context context);
Niall
----- Original Message ----- From: "Don Brown" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, May 26, 2004 4:58 PM
Subject: Re: [validator] Why doesn't commons-validator include functional
validators?
removeYes, in my view, validator config should refer directly to the validator being used. This makes the config more readable, IMO. I thought about making a FieldChecks-type facade object for commons-validator, but the adapter methods - i.e. isValid(Object bean, Field field) - still need to be generated for each validator and I think it is cleaner to, when adding a new validator or changing an existing, only have to modify one file, the validator, rather than the validator and the facade.
To help solve the duplication, I've created a SimpleValidator abstract class that has two methods:
public boolean isValid(Object bean, Field field); public abstract boolean isValid(String val);
For the simple validators, they could extend this class and only implement the abstract method. I'm not sure what else one could do since the limiting factor is the unique signatures of the actual validation method.
Don
David Graham wrote:
--- Don Brown <[EMAIL PROTECTED]> wrote:
So would you configure <validator> xml elements that referenceJust to be clear, the approach I feel would be simplest is to add "isValid(Object bean, Field field)"-type methods to each validator. This
way, the validators commons-validator provides can be used as they are or front-ended like how Struts' FieldChecks class interacts with them.
DateValidator directly instead of FieldChecks? Would we be able to
some of FieldChecks' methods?
I've already gone through several validators, adding unit tests as I go,
and things are looking good. Before I finish the rest of the validators,
however, I want to make sure this is a good idea in the eyes of everyone
else.
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
Are these steps going to be duplicated for every pluggable validator? If so, maybe we could front DateValidator and friends with something like FieldChecks that contains the glue code?
David
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]
__________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
