|
This is designed to solve a few simple issues related to wizard-like functionality in WebWork. One of those issues is
that some applications have a application-wide parameters commonly used, such pageLen (used for records per
page). Rather than requiring that each action check if such parameters are supplied, this interceptor can look for
specified parameters and pull them out of the session.
This works by setting listed properties at action start with values from session/application attributes keyed
after the action's class, the action's name, or any supplied 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 the session level. It doesn't guarantee application level
consistency however there has yet to be enough reasons to do so. Application level consistency would also be a big
performance overkill.
Note that this interceptor takes a snapshot of action properties just before result is presented (using a
PreResultListener ), rather than after action is invoked. 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.
Interceptor 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
- 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.
Extending the interceptor:
There are no know extension points for this interceptor.
Example code:
<!-- As the filter and orderBy parameters are common for all my browse-type actions,
you can move control to the scope interceptor. In the session parameter you can list
action properties that are going to be automatically managed over session. You can
do the same for application-scoped variables-->
<action name="someAction" class="com.examples.SomeAction">
<interceptor-ref name="basicStack"/>
<interceptor-ref name="hibernate"/>
<interceptor-ref name="scope">
<param name="session">filter,orderBy</param>
<param name="autoCreateSession">true</param>
</interceptor-ref>
<result name="success">good_result.ftl</result>
</action>
author:
Mike Mosiewicz
author:
Rainer Hermanns |
