that facade method sounds great, i use in JSF-Apps the "business logic" of some commons validators ;-)
Cheers, > -----Original Message----- > From: Niall Pemberton [mailto:[EMAIL PROTECTED] > 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" <[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? > > > > 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 <[EMAIL PROTECTED]> 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 <[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]
