Why not let everything be pluggable, the way it is in WebWork/Action2 ? In Action 1.3, we introduced using a Chain of Responsiblity to construct the Request Processor. Now anyone can construct any type of request processing cycle they like, just by plugging in different commands. The chain we have now needs work, but the concept is sound.
Proof that the concept is sound is the way WebWork uses Interceptors. Here, we have what amounts to a Chain, but it is configurable not only for the application, but for each individual Action. If we want the Struts Action 1.x codebase to be more configurable than it already is, my suggestion would be follow WebWork's lead, and expose the Request Processing chain though every Action. And, configure it all from a unified Struts Configuration, just as WebWork does. What's needed for the default configuration could ship in the regular distribution, and popular alternatives could be available through the Extras package. One thing I've been meaing to do is move the ValidatorActionForm and DynaValidatorActionForm to the Extras package, so that they stop confusing people. If there's interest in an Action 1.4, we could also finally make Action and ActionForms an interface, since I think the arguments against those interfaces have long since run out of steam. -Ted. On 1/29/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > Here's an idea. It is probably an enhancement that could work for 1.3.1+ or > 1.4 and I'd like to hear other people's thoughts: > > I would like to open up form validation to different kind of validating > strategies. For instance, right now there are two strategies: one validates > off form names, another off the action. What if there wanted to be a third? > I initially thought of this proposal as an incremental enhancement: > http://issues.apache.org/bugzilla/show_bug.cgi?id=38375 > > But I think there is always a bigger approach which I am shooting for. > Today, I wanted to create a subclass of ValidatorActionForm which would > contain some data points I wanted to share. But then I noticed some of my > forms are also ValidatorForm. There's a heirarchy here just for choosing > keys. > > I recommend this: > > We allow an ActionForm to contain pluggable validation strategies. These > could then validate off the key, the URI, or any other custom strategy that > can be plugged in. Perhaps the strategy validates using Spring validation > instead. This could really open up some possibilities. > > In conclusion, there would be no strict need to have a special subclasses > of ActionForm only for validation. We could then promote the use of > ActionForm with pluggable strategies. But for convienence, the ValidatorForm > and ValidatorActionForm would continue sticking around with the appropriate > strategy already set. > > What do you think? > > Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
