commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <mr...@twdata.org>
Subject Re: [validator] Why doesn't commons-validator include functional validators?
Date Wed, 26 May 2004 15:58:53 GMT
Yes, 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 <mrdon@twdata.org> wrote:
>  
>
>>Just 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. 
>>    
>>
>
>So would you configure <validator> xml elements that reference
>DateValidator directly instead of FieldChecks?  Would we be able to remove
>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 <mrdon@twdata.org> 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: commons-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>
>>>	
>>>		
>>>__________________________________
>>>Do you Yahoo!?
>>>Yahoo! Domains – Claim yours for only $14.70/year
>>>http://smallbusiness.promotions.yahoo.com/offer 
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>> 
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>    
>>
>
>
>
>	
>		
>__________________________________
>Do you Yahoo!?
>Friends.  Fun.  Try the all-new Yahoo! Messenger.
>http://messenger.yahoo.com/ 
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message