commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <maili...@matthias-wessendorf.de>
Subject RE: [validator] Why doesn't commons-validator include functional validators?
Date Wed, 26 May 2004 17:22:10 GMT
that facade method sounds great,

i use in JSF-Apps the "business logic"
of some commons validators ;-)

Cheers,


> -----Original Message-----
> From: Niall Pemberton [mailto:niall.pemberton@blueyonder.co.uk] 
> Sent: Wednesday, May 26, 2004 7:17 PM
> To: Jakarta Commons Developers List
> Subject: Re: [validator] Why doesn't commons-validator 
> include functional validators?
> 
> 
> 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" <mrdon@twdata.org>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Wednesday, May 26, 2004 4:58 PM
> Subject: Re: [validator] Why doesn't commons-validator 
> include functional validators?
> 
> 
> > 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
> >
> >
> >
> 
> 
> 
> ---------------------------------------------------------------------
> 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