You are correct, but in my opinion, these user commands that are placed in the Struts request processing chain should have relevance to your entire application and therefore are appropriate in the global level of the request processing chain. An action is about how to process an individual request, so in my book, these are two separate concerns that should be clearly separated.
There is a middle ground which I have been playing with on and off frequently called "interceptors". In WebWork2, you can define action interceptors that intercept certain actions, defined at a per-action level. With Struts Action Invocation Framework (SAIF) at struts.sf.net/saif , we ported interceptors to pre-chain Struts, but it would be interesting to integrate that work with Struts as it is now. It would be nice to define code that would be executed only before certain groups of actions. Don On Wed, 16 Feb 2005 08:10:04 -0800, Shey Rab Pawo <[EMAIL PROTECTED]> wrote: > On Sun, 13 Feb 2005 23:09:07 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > > See some thoughts and an implicit question within: > > > You make some good points, so I'll add my 2c: > > 1. The chain logic should be separate from the application logic, which > > could, however, use common-chain. I'm fine with using a chain command > > to replace Action, as long as it can be made clear the line between the > > two processes. One defines how all requests should be processed, and > > the other, how this individual request should be handled. > > My understanding may be faulty but my understanding of the original > intent behind chains vis-a-vis actions was to extract the request > processor, break it down, and make it a chain of commands, so that > this would give the user the option of supplanting code in whatever > detail was required, desired or needed in the process of realizing the > preliminary steps in an action. Essentially, then, the idea was to > keep the action firmly ensconced in the role of a controller in the > web MVC pattern but to allow the potential of allowing choices and > improvements, or to make the early request processing (pre-model > processing) pluggable. Is this right? If so, then I might have some > suggestions, but, if not, then I probably do not understand what is > happening and would appreciate a 35,000 foot explanation, if that > seems appropriate at this point. > > -- > The radiance of all the stars does not equal a sixteenth part of the > moon's radiance, likewise, good deeds giving us merit, all these do > not equal a sixteenth part of the merit of loving-kindness.. > > --------------------------------------------------------------------- > 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]
