On Sun, 21 May 2006 12:44:02 -0700, Don Brown wrote:
> You can inherit packages and their defined defaults. Therefore, in this
> case, you could define the default interceptor stack and result type for
> a root package then not have to specify it in any action configs of that
> package or child packages.
I've always disliked this part of WebWork (forgive me if things are
different now, my understanding is based on older versions of WebWork).
Managing the order of the interceptors is important, and it usually ends
up being much simpler and less fragile just to let every action use the
full stack of interceptors rather than explicitly picking and choosing
separate stacks for each action. This in turn can hurt performance by
having to chain through unnecessary interceptors, or hurt app design by
discouraging fine-grained interceptors.
In another web framework I've worked on, the configuration defines exactly
two stacks of interceptors--one for actions, and one for views. However,
the common interface for the interceptors includes this method:
boolean enable(Mapping mapping)
At startup, the framework asks asks each interceptor in the chain whether
it should be enabled for each mapping. For example, if the interceptor
relies on copying information from the context to the Action, it can
return "false" if it can see that the Action impl for a particular mapping
does not have any setters. Other interceptors might only enable
themselves if the mapping URL matches a particular pattern. The framework
then uses this information to construct *mapping-specific* chains. The
interceptors in these chains are in the same order as the full chain
defined by the config, but some (or most) interceptors will be removed for
any given mapping.
Furthermore, there is a way to store interceptor-specific data in the
Mapping object itself. This enables interceptors to pre-calculate data in
the enable method which will speed request handling. For example, the
interceptor which copies information to the Action setters could cache an
array of Methods, or even generate some bytecode.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
