I think the WebWork2/XWork implementation of interceptors is pretty
spot on.  You define interceptors and interceptor stacks at the top of
your configuration file.  Then, in the action mapping, we'd add an
attribute called say "interceptor" which would be the name of an
interceptor stack or interceptor.  We could use "pre" and "post", but
post is really just an interceptor that only contains code on the
response.

However, since we already have this commons-chain framework,  perhaps
all we need is the "interceptor" attribute that would point to a chain
command.  Chain supports the notions of Filters and is more robust in
that interceptor stacks or chains could have child chains, etc.

If we did this, I would definately want to have better Spring
integration for commons-chain.  These interceptors would probably need
several key business objects and I'd perfer to pass as little in the
context as possible.

Don


On Fri, 18 Feb 2005 11:35:20 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 9:04 AM -0800 2/18/05, 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.
> >
> >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.
> 
> Yeah... I'm just starting to look into some of this fancy JavaScript
> XMLHttpRequest stuff that Martin's always going off about ;-) and I
> thought it made sense to be able to define a chain whereby the posted
> XML gets converted into an object and placed into request scope in a
> routine fashion.  I still don't even have a complete model in my head
> about what I would need to do to service requests like that, but this
> seems like a starting point.
> 
> It also might be nice if some kind of interceptor could be designed
> to save people the trouble of copying the default chain-config.xml if
> they want to add things to the Request Processing chain.  I have been
> thinking in terms of Maven preGoals and postGoals, but I'm not sure
> what the proper route to implementation would be.
> 
> Joe
> 
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to