...
Interceptor | Name | Description |
---|---|---|
alias | Converts similar parameters that may be named differently between requests. | |
chain | Makes the previous Action's properties available to the current Action. Commonly used together with <result type="chain"> (in the previous Action). | |
checkbox | Adds automatic checkbox handling code that detect an unchecked checkbox and add it as a parameter with a default (usually 'false') value. Uses a specially named hidden field to detect unsubmitted checkboxes. The default unchecked value is overridable for non-boolean value'd checkboxes. | |
cookie | Inject cookie with a certain configurable name / value into action. (Since 2.0.7.) | |
conversionError | Adds conversion errors from the ActionContext to the Action's field errors | |
createSession | Create an HttpSession automatically, useful with certain Interceptors that require a HttpSession to work properly (like the TokenInterceptor) | |
debugging | Provides several different debugging screens to provide insight into the data behind the page. | |
execAndWait | Executes the Action in the background and then sends the user off to an intermediate waiting page. | |
exception | Maps exceptions to a result. | |
fileUpload | An Interceptor that adds easy access to file upload support. | |
i18n | Remembers the locale selected for a user's session. | |
logger | Outputs the name of the Action. | |
store | Store and retrieve action messages / errors / field errors for action that implements ValidationAware interface into session. | |
modelDriven | If the Action implements ModelDriven, pushes the | |
scopedModelDriven | If the Action implements ScopedModelDriven, the interceptor retrieves and stores the model from a scope and sets it on the action calling | |
params | Sets the request parameters onto the Action. | |
prepare | If the Action implements Preparable, calls its | |
scope | Simple mechanism for storing Action state in the session or application scope. | |
servletConfig | Provide access to Maps representing HttpServletRequest and HttpServletResponse. | |
staticParams | Sets the | |
roles | Action will only be executed if the user has the correct JAAS role. | |
timer | Outputs how long the Action takes to execute (including nested Interceptors and View) | |
token | Checks for valid token presence in Action, prevents duplicate form submission. | |
tokenSession | Same as Token Interceptor, but stores the submitted data in session when handed an invalid token | |
validation | Performs validation using the validators defined in action-validation.xml | |
workflow | Calls the | |
N/A | Removes parameters from the list of those available to Actions | |
profiling | Activate profiling through parameter | |
multiselect | Like the checkbox interceptor detects that no value was selected for a field with multiple values (like a select) and adds an empty parameter |
Warning |
---|
Since 2.0.7, Interceptors and Results with hyphenated names were converted to camelCase. (The former model-driven is now modelDriven.) The original hyphenated names are retained as "aliases" until Struts 2.1.0. For clarity, the hyphenated versions are not listed here, but might be referenced in prior versions of the documentation. |
...
Interceptor Parameter Overriding
Wiki Markup |
---|
{snippet:id=parameterOverriding|javadoc=true|url=com.opensymphony.xwork2.interceptor/Interceptor.java} |
Interceptor Parameter Overriding Inheritance
Parameters override are not inherited in interceptors, meaning that the last set of overridden parameters will be used. For example, if a stack overrides the parameter "defaultBlock" for the "postPrepareParameterFilter" interceptor as:
Interceptor's parameter could be overriden through the following ways :
Method 1:
Code Block | ||||
---|---|---|---|---|
| ||||
<action name="myAction" class="myActionClass">
<interceptor-ref name="exception"/>
<interceptor-ref name="alias"/>
<interceptor-ref name="params"/>
<interceptor-ref name="servletConfig"/>
<interceptor-ref name="prepare"/>
<interceptor-ref name="i18n"/>
<interceptor-ref name="chain"/>
<interceptor-ref name="modelDriven"/>
<interceptor-ref name="fileUpload"/>
<interceptor-ref name="staticParams"/>
<interceptor-ref name="params"/>
<interceptor-ref name="conversionError"/>
<interceptor-ref name="validation">
<param name="excludeMethods">myValidationExcudeMethod</param>
</interceptor-ref>
<interceptor-ref name="workflow">
<param name="excludeMethods">myWorkflowExcludeMethod</param>
</interceptor-ref>
</action>
Method 2:
{code:xml}
<action name="myAction" class="myActionClass">
<interceptor-ref name="defaultStack">
<param name="validation.excludeMethods">myValidationExcludeMethod</param>
<param name="workflow.excludeMethods">myWorkflowExcludeMethod</param>
</interceptor-ref>
</action>
|
In the first method, the whole default stack is copied and the parameter then changed accordingly.
In the second method, the interceptor-ref
refers to an existing interceptor-stack, namely defaultStack
in this example, and override the validator
and workflow
interceptor excludeMethods
attribute. Note that in the param
tag, the name attribute contains a dot (.) the word before the dot(.) specifies the interceptor name whose parameter is to be overridden and the word after the dot (.) specifies the parameter itself. The syntax is as follows:
Code Block |
---|
<interceptor-name>.<parameter-name>
|
Note also that in this case the interceptor-ref
name attribute is used to indicate an interceptor stack which makes sense as if it is referring to the interceptor itself it would be just using Method 1 describe above.
Code Block | ||
---|---|---|
h3. Interceptor Parameter Overriding Inheritance
Parameters override are not inherited in interceptors, meaning that the last set of overridden parameters will be used. For example, if a stack overrides the parameter "defaultBlock" for the "postPrepareParameterFilter" interceptor as:
{code:xml} | ||
Code Block | ||
xml | xml | <interceptor-stack name="parentStack"> <interceptor-ref name="postPrepareParameterFilter"> <param name="defaultBlock">true</param> </interceptor-ref> </interceptor-stack> |
...
Interceptors provide an excellent means to wrap before/after processing. The concept reduces code duplication (think AOP).
Code Block | ||||
---|---|---|---|---|
| ||||
<interceptor-stack name="xaStack"> <interceptor-ref name="thisWillRunFirstInterceptor"/> <interceptor-ref name="thisWillRunNextInterceptor"/> <interceptor-ref name="followedByThisInterceptor"/> <interceptor-ref name="thisWillRunLastInterceptor"/> </interceptor-stack> |
...