You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Introduction

The Scope Interceptor was at first written to solve a few simple issues. One of them was that in one application I had a few application-wide parameters commonly used like for example pageLen (records per page). I wanted to have something similar to ParameterInterceptor to cope with them. I didn't like that in each action I had to check if any of those parameters is attached to session, copy them, etc. So I created this interceptor to deal with them.

Then instead of dealing with session scoped parameters by hand I used a familiar IoC pattern. Here is an example interceptor stack from my application:

<interceptor-stack name="defBrowseInterceptorStack">
    <interceptor-ref name="defaultStack"/>
    <interceptor-ref name="hibernate"/>
    <interceptor-ref name="scope" >
        <param name="session">filter,orderBy</param>
    </interceptor-ref>
    <interceptor-ref name="params"/>
</interceptor-stack>

As the filter and orderBy parameters are common for all my browse-type actions, I can move the control over them to ScopeInterceptor. In the session parameter I can list action properties that are going to be automatically managed over session. Similary I can manage application scoped variables.

ScopeInterceptor works by setting listed properties at action start with values from session/application attributes keyed after action class, action name or any chosen key. After action is executed all the listed properties are taken back and put in session or application context.

To make sure that each execution of the action is consistent it makes use of session level locking. This way it guarantees that each action execution is atomic at session level. It doesn't guarantee application level consistency however because I haven't found enough reasons to do so. Application level consistency would be a big performance overkill.

Note that this interceptor takes a snapshot of action properties just before result is presented (using PreResultListener technique), not after action is invoked and there is a reason for that. At this moment we know that action's state is "complete" as it's values may depend on the rest of the stack and specifically - on the values of nested interceptors.

Scope Interceptor parameters

ScopeInterceptor can be set with the following parameters:

  • session - a list of action properties to be bound to session scope
  • application - a list of action properties to be bound to application scope

key - a session/application attribute key prefix, can contain following values:

  • CLASS - that creates a unique key prefix based on action namespace and action class, it's a default value
  • ACTION - creates a unique key prefix based on action namespace and action name
  • any other value is taken literally as key prefix

type - with one of the following:

  • start - means it's a start action of the wizard-like action sequence and all session scoped properties are reset to their defaults,
  • end - means that session scoped properties are removed from session after action is run
  • any other value or no value means that it's in-the-middle action that is set with session properties before it's executed, and it's properties are put back to session after execution

In a newer version (hopefully to be committed by Pat) I also added:

  • sessionReset - boolean value causing all session values to be reset to action's default values or application scope values, note that it is similliar to type="start" and in fact it does the same, but in our team it is sometimes semantically preferred. We use session scope in two patterns - sometimes there are wizzard-like action sequences that have start and end, and sometimes we just want simply reset current session values.

That newer version also responds to "session.reset" request parameter.

  • No labels