ActionMapper
The ActionMapper is responsible for providing a mapping between HTTP requests and action invocation requests and
vice-versa. When given an HttpServletRequest, the ActionMapper may return null if no action invocation request maps,
or it may return an ActionMapping that describes an action invocation that WebWork should attempt to try. The
ActionMapper is not required to guarantee that the ActionMapping returned be a real action or otherwise
ensure a valid request. This means that most ActionMappers do not need to consult WebWork's configuration to
determine if a request should be mapped.
Just as requests can be mapped from HTTP to an action invocation, the opposite is true as well. However, because
HTTP requests (when shown in HTTP responses) must be in String form, a String is returned rather than an actual
request object.
ActionMapper should return null (#getMapping(javax.servlet.http.HttpServletRequest) and
#getUriFromActionMapping(ActionMapping) if it cannot handle the context.
DefaultActionMapper
By default, the DefaultActionMapper is used:
Default action mapper implementation, using the standard *.[ext] (where ext usually "action") pattern. The extension
is looked up from the WebWork configuration key webwork.action.exection.
To help with dealing with buttons and other related requirements, this mapper (and other ActionMappers,
we hope) has the ability to name a button with some predefined prefix and have that button name alter the execution
behaviour. The four prefixes are:
- Method prefix - method:default
- Action prefix - action:dashboard
- Redirect prefix - redirect:cancel.jsp
- Redirect-action prefix - redirect-action:cancel
In addition to these four prefixes, this mapper also understands the action naming pattern of foo!bar in
either the extension form (eg: foo!bar.action) or in the prefix form (eg: action:foo!bar). This syntax tells this mapper
to map to the action named foo and the method bar.
Method prefix
With method-prefix, instead of calling baz action's execute() method (by default if it isn't overriden in xwork.xml
to be something else), the baz action's anotherMethod() will be called. A very elegant way determine which button is
clicked. Alternatively, one would have submit button set a particular value on the action when clicked, and the
execute() method decides on what to do with the setted value depending on which button is clicked.
<ww:form action="baz">
<ww:textfield label="Enter your name" name="person.name"/>
<ww:submit value="Create person"/>
<ww:submit name="method:anotherMethod" value="Cancel"/>
</ww:form>
Action prefix
With action-prefix, instead of executing baz action's execute() method (by default if it isn't overriden in xwork.xml
to be something else), the anotherAction action's execute() method (assuming again if it isn't overriden with
something else in xwork.xml) will be executed.
<ww:form action="baz">
<ww:textfield label="Enter your name" name="person.name"/>
<ww:submit value="Create person"/>
<ww:submit name="action:anotherAction" value="Cancel"/>
</ww:form>
Redirect prefix
With redirect-prefix, instead of executing baz action's execute() method (by default it isn't overriden in xwork.xml
to be something else), it will get redirected to, in this case to www.google.com. Internally it uses
ServletRedirectResult to do the task.
<ww:form action="baz">
<ww:textfield label="Enter your name" name="person.name"/>
<ww:submit value="Create person"/>
<ww:submit name="redirect:www.google.com" value="Cancel"/>
</ww:form>
Redirect-action prefix
With redirect-action-prefix, instead of executing baz action's execute() method (by default it isn't overriden in
xwork.xml to be something else), it will get redirected to, in this case 'dashboard.action'. Internally it uses
ServletRedirectResult to do the task and read off the extension from the webwork.properties.
<ww:form action="baz">
<ww:textfield label="Enter your name" name="person.name"/>
<ww:submit value="Create person"/>
<ww:submit name="redirect-action:dashboard" value="Cancel"/>
</ww:form>
CompositeActionMapper
This is an ActionMapper that could take in ActionMappers and consult each ActionMapper
in the order they are given where ActionMapper with higher order will take precedence.
The pre-defined ActionMappers could be configured in 2 ways :-
- Through webwork.properties - #CompositeActionMapper()
- Through parameters passed in to the constructor of CompositeActionMapper -
#CompositeActionMapper(ActionMapper[])
Through webwork.properties
CompositeActionMapper does this by reading in the pre-configured ActionMappers
through webwork.properties file eg. with
webwork.mapper.class=com.opensymphony.webwork.dispatcher.mapper.CompositeActionMapper
webwork.compositeActionMapper.1=com.opensymphony.webwork.dispatcher.mapper.RestfulActionMapper
webwork.compositeActionMapper.2=com.opensymphony.webwork.dispatcher.mapper.DefaultActionMapper
We would have configured a CompositeActionMapper, with 2 pre-configured ActionMappers, namely
- com.opensymphony.webwork.dispatcher.mapper.RestfulActionMapper
- com.opensymphony.webwork.dispatcher.mapper.DefaultActionMapper
where RestfulActionMapper will be consulted first before DefaultActionMapper as it has a higher order.
ActionMapper with a lower order will be consulted first.
Through constructor (normally for unit testing)
CompositeActionMapper does this with the pre-configured ActionMappers
passed in as an array. The order of the ActionMappers is important as they will be consulted
in order.
ActionMapperFactory
You can define your own ActionMapper by configuring the ActionMapperFactory:
Factory that creates ActionMappers. This factory looks up the class name of the ActionMapper from
WebWork's configuration using the key webwork.mapper.class.
Possible uses of the ActionMapper include defining your own, cleaner namespaces, such as URLs like /person/1, which would be similar to a request to /getPerson.action?personID=1 using the DefaultActionMapper.
|