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.
This may be a reason for pushing in a direction I'd been mulling but hadn't implemented: break up "process-action" into parts. I don't like that everything after ValidateActionForm needs to have a hard-coded "check if form was valid" test; that shouldn't be built into the command, but rather should be part of the chain design. So maybe from a big picture,
In short form, here's what it is now:
servlet-standard (chain command): command: ExceptionCatcher lookup: process-action lookup: process-view
into something like this: servlet-standard (chain command): command: ExceptionCatcher lookup: preprocess-action lookup: process-form conditional lookup: process-invalid-form conditional lookup: process-valid-form lookup: process-view
where the current process-action would break down like this:
"preprocess-action" lookup: servlet-standard-preprocess command: SelectLocale command: RequestNoCache command: SetContentType command: SelectAction command: AuthorizeAction
"process-form" command: CreateActionForm command: PopulateActionForm command: ValidateActionForm
"process-invalid-form" command: SelectInput
"process-valid-form" command: ExecuteCommand command: SelectForward command: SelectInclude command: PerformInclude command: CreateAction command: ExecuteAction
In that case, the "process-valid-form" could be wrapped in the interceptor (or do you also want to intercept the form part?)
It seems like it would be pretty easy to write a variant of the Chain class which, when given an interceptor map, could use the name of each command it found to look for a registered interceptor, and use it to wrap the command. Except for your concern about avoiding putting things in the context, this seems like it might be a good candidate for inclusion in the core commons-chain library. Perhaps a base implementation could go there, and it could be elaborated for dependency injection.
All of this sounds like a good candidate for Struts.SF.net for the foreseeable future...
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]
