On Fri, 18 Feb 2005 09:04:32 -0800, Don Brown wrote: > 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.
+1 There should be a clear separation between * the logic that is processing the request, and * the the logic that is processing the transaction implied by the request. Of course, some people are going to muddle the two no matter what we do, but we should try to encourage a design that separates concerns. > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
