The validator is a nice piece of work but its not the only game in town. I agree that its a good idea to provide a default component for people to use, but I don't agree that it's a good idea to link it to the base ActionForm.
Right now, if the Validator is not used, the code just sits there in the jar. But if you build it into the subclass of ActionForm, it gets called (even to return null) and starts to consume resources. It is true that most applications need a validation step. That's why we have a validation hotspot. But I don't agree that we need to hardwire the Validator into the ActionForm. My true feeling is that the Validator is a fine start, but there is still a lot to be learned about validation, and we should not standardize too early. I'm now working on a design that pushes all the Validation back to the business tier. We will probably still use the Validator, but the Commons-Validator rather than the Struts Validator. The ActionForm will be use to create the business request and call it's validation method. The business request can then pass back the tokenized messages, just like the Struts validate method. But we end up with people working on common business classes that we can re-use between platforms. (Nothing out of the Struts jar.) I just bring this up to point out that not everyone is just writing web applications or Struts applications or blindly using the Struts hotspots just because they are there. It's the job of the framework to make services available, but we need to be very conservative about which services we wire into our own *base* classes that we compell people ot use. If nothing else, both the Validator and Tiles are proofs of concept about how developers can connect their own extensions to Struts. If we start hardwiring everything in, we start to loose the open aspect of the architechture. It's true that wiring more in would be more convenient, but there's such a thing as being too convenient. (A lesson Turbine learned the hard way.) -Ted. 10/25/2002 1:42:20 PM, David Graham <[EMAIL PROTECTED]> wrote: >Thanks for the input Ted. I was only suggesting changing struts-config if >validator was truely merged; I agree that optional components don't belong >there. The validation rules file should be separate but I'm suggesting that >the validator not be a plugin and have an entry similar to message-resources >or form-beans. > >Now the question is whether the validator is a core component? >I don't know what you all define as core but I believe this is a core >aspect. How many forms have you built that didn't need validation of at >least one required field (if no form fields are required I question the >value of the form)? > >What are the various options for validation? I see 2 built into Struts: >coding a form bean's validate() method and using the validator. What I'm >suggesting is that the ActionForm.validate() method use the validator by >default. > >I just don't see any need to subclass a different ActionForm class to use >the validator when it seems that this will become the predominant form of >validation. > >David > > > > > > >>From: Ted Husted <[EMAIL PROTECTED]> >>Reply-To: "Struts Developers List" <struts- [EMAIL PROTECTED]> >>To: Struts Developers List <[EMAIL PROTECTED]> >>Subject: Re: Validator Integration >>Date: Fri, 25 Oct 2002 13:09:10 -0400 >> >>I've been using the Validator for going on three years now, but >>I don't think I would ever want to describe it as an integal >>part of Struts. Struts provides a validation hotspot, and we >>provide the Validation as something people can plug into that >>spot. But we want to be very clear that it is only one of many >>possible solutions to validation. >> >>We provide direct support for the Validator as a convenience, >>but IMHO, it is not part of the true Struts core. (Of course, I >>don't consider the tags part of the true Struts core either =:) >> >>I'd also be very cold on amending the struts-config with the >>specifics for any optional component, the Validator included. >>Ideally, the Validation config could be shared with other >>platforms (not just Struts), and should be a standalone file. >> >>As mentioned elsewhere, there were two classes since some >>people (or maybe one person) wanted to key on the action path >>rather than the action attribute. But if we were patch this to >>use a switch, mores the better. >> >>-Ted. >> >>10/25/2002 10:34:52 AM, David Graham <dgraham1980 @hotmail.com> >>wrote: >> >> >It struck me the other day that the validator could be further >>integrated >> >into struts. I'm not sure about my ideas so I want to get >>your thoughts. y >> >Why should people need to subclass ValidatorActionForm instead >>of ActionForm >> >to use the validator? What forms have you built that didn't >>need >> >validation? >> > >> >My idea is that the ValidatorActionForm and ValidatorForm (why >>are there 2?) >> >behavior should be included in ActionForm and have those >>classes removed. I >> >think this will maintain backward compatibility because if the >>developer >> >hasn't defined any validation rules for a form then we could >>return null >> >from validate(). >> > >> >Further, we could include validator configuration tags in >>struts-config.xml >> >instead of using a plugin. This would signify that validator >>is an integral >> >piece of struts that most people want to use (which I believe >>they do). >> > >> >This is probably a post 1.1 idea but I thought I'd throw it >>out here. >> >What do you think? >> > >> >David >> > >> > >> > >> > >> > >> > ______________________________________________________________ >>___ >> >Unlimited Internet access -- and 2 months free! Try MSN. >> >http://resourcecenter.msn.com/access/plans/2monthsfree.asp >> > >> > >> >-- >> >To unsubscribe, e-mail: <mailto:struts-dev- >>[EMAIL PROTECTED]> >> >For additional commands, e-mail: <mailto:struts-dev- >>[EMAIL PROTECTED]> >> > >> > >> >> >> >> >>-- >>To unsubscribe, e-mail: >><mailto:struts-dev-unsubscribe@;jakarta.apache.org> >>For additional commands, e-mail: >><mailto:struts-dev-help@;jakarta.apache.org> > > >______________________________________________________________ ___ >Protect your PC - get McAfee.com VirusScan Online >http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > >-- >To unsubscribe, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>