The action mappings are the basic "unit-of-work" in the framework. Essentially, the action maps an identifier to a handler class. When a request matches the action's name, the framework uses the mapping to determine how to process the request.
Action Mappings
The action mapping can specify a set of result types, a set of exception handlers, and an interceptor stack. But, only the name
attribute is required. The other attributes can also be provided at package scope.
<action name="Logon" class="tutorial.Logon"> <result type="redirect-action">Menu</result> <result name="input">/tutorial/Logon.jsp</result> </action>
Action Names
In a web application, the name
attribute is matched a part of the location requested by a browser (or other HTTP client). The framework will drop the host and application name and the extension, and match what's in the middle. So, a request for http://www.planetstruts.org/struts2-mailreader/Welcome.do
will map to the Welcome
action.
Within an application, the link to an action is usually generated by a Struts Tag. The tag can specify the action by name, and the framework will render the default extension and anything else that is needed.
<s:form action="Hello"> <s:textfield label="Please enter your name" name="name"/> <s:submit/> </s:form>
Action Names With Slashes
If your action names have slashes in them (for example, <action name="admin/home" class="tutorial.Admin"/>
) you need to specifically enable that functionality via the struts.properties
file by specifying struts.enable.SlashesInActionNames = true
. See JIRA Issue WW-1383 for discussion as there are side effects to setting this property to true
.
Action Methods
The default entry method to the handler class is defined by the Action interface.
public interface Action { public String execute() throws Exception; }
Implementing the Action interface is optional. If Action is not implemented, the framework will use reflection to look for an execute
method.
Sometimes, developers like to create more than one entry point to an Action. For example, in the case of of a data-access Action, a developer might want separate entry-points for create
, retrieve
, update
, and delete
. A different entry point can be specified by the method
attribute.
<action name="delete" class="example.CrudAction" method="delete">
If there is no execute
method, and no other method, specified in the configuration, the framework will throw an exception.
Wildcard Method
Many times, a set of action mappings will share a common pattern. For example, all your edit
actions might start with the word "edit", and call the edit
method on the Action class. The delete
actions might use the same pattern, but call the delete
method instead.
Rather than code a separate mapping for each action class that uses this pattern, you can write it once as a wildcard mapping.
<action name="*Crud" class="example.Crud" method="{1}">
Here, a reference to "editCrud" will call the edit
method on an instance of the Crud Action class. Likewise, a reference to "deleteCrud" will call the delete
method instead.
Another common approach is to postfix the method name and set it off with an exclamation point (aka "bang"), underscore, or other special character.
- "action=Crud_input"
- "action=Crud_delete"
To use a postfix wildcard, just move the asterisk and add an underscore.
<action name="Crud_*" class="example.Crud" method="{1}">
From the framework's perspective, a wildcard mapping creates a new "virtual" mapping with all the same attributes as a conventional, static mapping. As a result, you can use the expanded wildcard name as the name of validation, type conversion, and localization files, just as if it were an Action name (which it is!).
Crud_input-validation.xml
Crud_delete-conversion.xml
The postfix "!" notation is also available in WebWork 2, but it is implemented differently. To use the old implementation, set struts.enable.DynamicMethodInvocation=TRUE
in the struts.properties
file. To use wildcards instead (preferred), set struts.enable.DynamicMethodInvocation=FALSE
.
ActionSupport Default
If the class attribute in an action mapping is left blank, the com.opensymphony.xwork.ActionSupport
class is used as a default.
<action name="Hello"> // ... </action>
The ActionSupport class has execute
and input
methods that return "success".
Post-Back Default
A good practice is to link to actions rather than pages. Linking to actions encapsulates which server page renders, and ensures that an Action class can fire before a page renders.
Another common workflow stategy is to first render a page using an alternate method, like input
and then have it submit back to the default execute
method.
Using these two strategies together creates an opportunity to use a "post-back" form that doesn't specify an action. The form simply submits back to the action that created it.
<s:form> <s:textfield label="Please enter your name" name="name"/> <s:submit/> </s:form>
Action Default
Usually, if an action is requested, and the framework can't map the request to an action name, the result will be the usual "404 - Page not found" error. But, if you would prefer that an ominbus action handle any unmatched requests, you can specify a default action. If no other action matches, the default action is used instead.
<package name="Hello" extends="action-default"> <default-action-ref name="UnderConstruction"> <action name="UnderConstruction"> <result>/UnderConstruction.jsp</result> </action>
There are no special requirements for the default action. Each package can have its own default action, but there should only be one default action per namespace.
One to a Namespace
The default action features should be setup so that there is only one default action per namespace. If you have multiple packages declaring a default action with the same namespace, there is no guarantee which action will be the default.
Wildcard Default
Using wildcards is another approach to default actions. A wildcard action at the end of the configuration can be used to catch unmatched references.
<action name="*" > <result>/{1}.jsp</result> </action>
When a new action is needed, just add a stub page.
FAQ
How can we display dynamic or static images that can be provided as an array of bytes?
How can we test Actions?
How can we force the Action Mappings (struts.xml) to reload?