Most use cases can be divided into two phases. First, we need to change or query the application's state, and then we need to present an updated view of the application. The Action class manages the application's state, and the Result Type manages the view.
Predefined Result Types
The framework
Overview
Result Types are classes that determine what happens after an Action executes and a Result is returned. Developers are free to create their own Result Types according to the needs of their application or environment. In WebWork 2 for example, Servlet and Velocity Result Types have been created to handle rendering views in web applications.
Note: All built in webwork result types implement the com.opensymphony.xwork.Result
interface, which represents a generic interface for all action execution results, whether that be displaying a webpage, generating an email, sending a JMS message, etc.
Result types define classes and map them to names to be referred in the action configuration results. This serves as a shorthand name-value pair for these classes.
Code Block |
---|
<!-- parts of xwork.xml -->
....
<result-types>
<result-type name="dispatcher" class="com.opensymphony.webwork.dispatcher.ServletDispatcherResult" default="true"/>
<result-type name="redirect" class="com.opensymphony.webwork.dispatcher.ServletRedirectResult"/>
<result-type name="velocity" class="com.opensymphony.webwork.dispatcher.VelocityResult"/>
<result-type name="chain" class="com.opensymphony.xwork.ActionChainResult"/>
<result-type name="xslt" class="com.opensymphony.webwork.views.xslt.XSLTResult"/>
<result-type name="jasper" class="com.opensymphony.webwork.views.jasperreports.JasperReportsResult"/>
<result-type name="freemarker" class="com.opensymphony.webwork.views.freemarker.FreemarkerResult"/>
</result-types>
....
<!-- this action uses the result type dispatcher which is defined above -->
<action name="bar" class="myPackage.barAction">
<result name="success" type="dispatcher">
<param name="location">foo.jsp</param>
</result>
<result name="error" type="dispatcher">
<param name="location">error.jsp</param>
</result>
</action>
....
|
Result Types
Webwork provides several implementations of the com.opensymphony.xworkxwork2.Result
interface to make web-based interactions with your actions simple. These result types include:
Result Type | name | class |
---|---|---|
dispatcher | com.opensymphony.webwork.dispatcher.ServletDispatcherResult | |
redirect | com.opensymphony.webwork.dispatcher.ServletRedirectResult | |
chain | com.opensymphony.xwork.ActionChainResult | |
velocity | com.opensymphony.webwork.dispatcher.VelocityResult | |
freemarker | com.opensymphony.webwork.views.freemarker.FreemarkerResult | |
jasper | com.opensymphony.webwork.views.jasperreports.JasperReportsResult | |
xslt | com.opensymphony.webwork.views.xslt.XSLTResult | |
| com.opensymphony.webwork.dispatcher.HttpHeaderResult |
Results are specified in a xwork xml config file(xwork.xml) nested inside <action>. If the location
param is the only param being specified in the result tag, you can simplify it as follows:
Code Block |
---|
<action name="bar" class="myPackage.barAction">
<result name="success" type="dispatcher">
<param name="location">foo.jsp</param>
</result>
</action>
|
or simplified
Code Block |
---|
<action name="bar" class="myPackage.barAction">
<result name="success" type="dispatcher">foo.jsp</result>
</action>
|
NOTE: The Parse attribute enables the location element to be parsed for expressions. An example of how this could be useful:
Code Block |
---|
<result name="success" type="redirect">/displayCart.action?userId=${userId}</result>
|
NOTE: You can also specify global-results to use with multiple actions. This can save time from having to add the same result to many different actions. For more information on result tags and global-results, see Results section.
...
, ready to use in your own applications.
Used for Action Chaining | |
Used for web resource integration, including JSP integration | |
Used for FreeMarker integration | |
Used to control special HTTP behaviors | |
Used to redirect to another URL (web resource) | |
Used to redirect to another action mapping | |
Used to stream an InputStream back to the browser (usually for file downloads) | |
Used for Velocity integration | |
Used for XML/XSLT integration | |
Used to display the raw content of a particular page (i.e jsp, HTML) | |
Used to provide Tiles 2 integration | |
Used to provide Tiles 3 integration | |
Used to postback request parameters as a form to the specified destination | |
JSON Result | Used to serialize actions into JSON |
Optional
Used for JasperReports Tutorial integration | Optional, third-party plugin |
Additional Result Types can be created and plugged into an application by implementing the com.opensymphony.xwork2.Result
interface. Custom Result Types might include generating an email or JMS message, generating images, and so forth.
Default Parameters
To minimize configuration, Results can be configured with a single value, which will be converted into a parameter, and each Result can specify which parameter this value should be set as. For example, here is a result defined in XML that uses a default parameter:
Code Block | ||
---|---|---|
| ||
<result type="freemarker">foo.fm</result>
|
That is the equivalent to this:
Code Block | ||
---|---|---|
| ||
<result type="freemarker">
|
...
Includes or forwards to a view (usually a jsp). Behind the scenes WebWork will use a RequestDispatcher, where the target servlet/JSP receives the same request/response objects as the original servlet/JSP. Therefore, you can pass data between them using request.setAttribute() – the WebWork action is available.
Parameters | Required | Description |
---|---|---|
location | yes | the location to go to after execution (ex. jsp) |
parse | no | true by default. If set to false, the location param will not be parsed for Ognl expressions |
Code Block |
---|
<result name="success" type="dispatcher">
<param name="location">foo.jsp</param>
</result>
|
...
The response is told to redirect the browser to the specified location (a new request from the client). The consequence of doing this means that the action (action instance, action errors, field errors, etc) that was just executed is lost and no longer available. This is because actions are built on a single-thread model. The only way to pass data is through the session or with web parameters (url?name=value) which can be OGNL expressions.
Parameters | Required | Description |
---|---|---|
location | yes | the location to go to after execution |
parse | no | true by default. If set to false, the location param will not be parsed for Ognl expressions |
Code Block |
---|
<result name="success" type="redirect">
<param name="location">foo.jsp</param>
<param name="parse">false</param>
</result>
|
...
A special kind of view that invokes GenericDispatch (using the previously existing ActionContext) and executes another action. This is useful if you need to execute one action immediately after another.
Parameters | Required | Description |
---|---|---|
actionName | yes | the name of the action that will be chained to |
namespace | no | sets the namespace of the Action that we're chaining to. If namespace is null, this defaults to the current namespace. |
Code Block |
---|
<result name="success" type="chain">
<param name="actionName">bar</param>
<param name="namespace">/foo</param>
</result>
|
invokes this
Code Block |
---|
<action name="bar" class="myPackage.barAction">
...
</action>
|
...
This result mocks a JSP execution environment and then displays a Velocity template that will be streamed directly to the servlet output.
Parameters | Required | Description |
---|---|---|
location | yes | the location to go to after execution |
parse | no | true by default. If set to false, the location param will not be parsed for Ognl expressions |
Code Block |
---|
<result name="success" type="velocity">
<param name="location">foo.vm</param>
</result>
|
...
Parameters | Required | Description |
---|---|---|
location | yes | the location to go to after execution |
parse | no | true by default. If set to false, the location param will not be parsed for Ognl expressions |
contentType | no | defaults to "text/html" unless specified |
Code Block |
---|
<result name="success" type="freemarker">foo.ftl</result>
|
...
Generates a JasperReports report using the specified format or PDF if no format is specified.
Parameters | Required | Description |
---|---|---|
location | yes | the location to go to after execution |
parse | no | true by default. If set to false, the location param will not be parsed for Ognl expressions |
dataSource | yes | the Ognl expression used to retrieve the datasource from the value stack (usually a List) |
format | no | the format in which the report should be generated, defaults to pdf |
Code Block |
---|
<result name="success" type="jasper">
<param name="location">foo.jasper</param>
<param name="dataSource">mySource</param>
<param name="format">CSV</param>
</result>
|
or for pdf
Code Block |
---|
<result name="success" type="jasper">
<param name="location">foo.jasper</param>
<param name="dataSource">mySource</param>
</result>
|
...
Interfaces with xml transformations.
Parameters | Required | Description |
---|---|---|
location | yes | the location to go to after execution |
parse | no | Defaults to false. If set to true, the location will be parsed for Ognl expressions |
Code Block |
---|
<result name="success" type="xslt">foo.xslt</result>
|
...
A custom Result type for evaluating HTTP headers against the ValueStack.
Parameters | Required | Description |
---|---|---|
status | no | the http servlet response status code that should be set on a response |
parse | no | true by default. If set to false, the headers param will not be parsed for Ognl expressions |
headers | no | header values |
Example:
...
Since probably 95% of your actions won't need results that contain multiple parameters, this little shortcut saves you a significant amount of configuration. It also follows that if you have specified the default parameter, you don't need to set the same parameter as a specifically-named parameter.
Registering Result Types
All Result Types are plugged in via the Result Configuration.
Extending
You can always extend defined result types and implement whatever logic you need. To simplify process of that, you can define your custom ResultFactory
and use it with connection with custom interface which your Result implements. Check Define dedicated factory to see how to do it.
Struts 2 provides one such extension for you: ParamNameAwareResult
interface when used with StrutsResultBuilder
can limit parameters assigned to the result. So you can simple extend existing result with such a functionality as below:
Code Block | ||||
---|---|---|---|---|
| ||||
public class MyResult extends ServletDispatcherResult implements ParamNameAwareResult {
public boolean acceptableParamName(String name, String value) {
return "accept".equals(name);
}
}
|
and then register it and use instead of default dispatcher
result.
Next: DispatcherListener
...