Now the question becomes, how does MultiActionControllerknow which method
to call when it handles a request? This decision process is encapsulated into the strategy
MethodNameResolver, whose job it is to take an HttpServletRequestand return a method
name as a String.InternalPathMethodNameResolver
The default strategy, if none is specified, is the org.springframework.web.servlet.mvc.
multiaction.InternalPathMethodNameResolver. To quote the Javadocs, this strategy is a
“Simple implementation of MethodNameResolverthat maps URL to method name.” This class
will convert the last path section of the URL, ignoring any file extensions, into a method name.
For instance, it will turn /app/account/delete.xinto the method name delete.
If the method names in your controller vary in a uniform way from the URL path section,
then a prefix or suffix can be configured. For instance, if your method name is dodelete, but
you want to continue to use /app/account/delete.x, then you can configure the prefix prop-
erty of InternalPathMethodNameResolverto equal “do.”
Because this strategy is the default, no configuration is required if you choose to use it.
However, if you want to configure a prefix or suffix, then you will have to specify its bean defi-
nition. Listing 6-56 contains a sample configuration.Listing 6-56.Example Configuration of an InternalPathMethodNameResolver<bean id="methodNameResolver"
class="o.s.web.servlet.mvc.multiaction.InternalPathMethodNameResolver">
<property name="prefix" value="do" />
</bean>
<bean name="/account/*"
class="com.apress.expertspringmvc.flight.web.ViewAccountController">
<property name="methodNameResolver" ref="methodNameResolver" />
<property name="accountService" ref="accountService" />
</bean>ParameterMethodNameResolver
If you are looking for behavior that matches Struts’ DispatchAction, then you can use the
org.springframework.web.servlet.mvc.multiaction.ParameterMethodNameResolver. This
strategy actually is a combination of two separate strategies, both looking at request parame-
ters for method name resolution.
The first strategy will look for a parameter by name, and its value will be treated as the
method name. By default, the name of the parameter is action, but you can change it by call-
ing setParamName(). Unlike InternalPathMethodNameResolver, there are no prefix and suffix
capabilities, so the value of the action parameter must match exactly the method name.
The second strategy is to look for the mere presence of a request parameter, whose name
will point to the method name. The ParameterMethodNameResolverwill look for any parameter
whose name is found in the methodParamNamesarray, and the first match wins.170 CHAPTER 6 ■THE CONTROLLER MENAGERIE