Another two handy Spring MVC Controller

MultiActionController VS ParameterizableViewController

 

Have discussed “Validation with Spring MVC SimpleFormController” in the earlier note, which demonstrated you how handy it is to duel with forms. In this note, I would like to introduce another two handy controllers: MultiActionController and ParameterizableViewController.

 

ParameterizableViewController

The official JavaDoc introduced: “This controller offers an alternative to sending a request straight to a view such as a JSP. The advantage here is that the client is not exposed to the concrete view technology but rather just to the controller URL”. (Which controller is not?)  The advantage for using this controller is that you can simply set the view page straight away in the configuration rather than doing any coding in the controller.

 

MultiActionController is a bit more complex to configure, but would save you loads of time from writing many controllers that have common functions individually. multi-action controller with which you aggregate multiple actions into one controller, grouping functionality together.

 

There are two features offered by MutliActionController

Feature

Explanation

delegate

there are two usage-scenarios for the MultiActionController. Either you subclass the MultiActionController and specify the methods that will be resolved by the MethodNameResolver on the subclass (in which case you don’t need to set the delegate), or you define a delegate object, on which methods resolved by the Resolver will be invoked. If you choose this scenario, you will have to define the delegate using this configuration parameter as a collaborator.

methodNameResolver

somehow the MultiActionController will need to resolve the method it has to invoke, based on the request that came in. You can define a resolver that is capable of doing that using this configuration parameter.

 

The following example demonstrates how to apply the methodNameResolver feature.

 

 

<bean id=" multiTestController " class="com.hongliang.MultiTestController">

    <property name="methodNameResolver">

        <bean class="org.springframework.web.servlet.mvc.multiaction.ParameterMethodNameResolver">

            <property name="methodParamNames">

                <list>

                    <value>viewBooks</value>

                    <value>viewArticles</value>

                </list>

            </property>

            <property name="logicalMappings">

                <props>

                    <prop key=" viewBooks ">displayBooks</prop>

                    <prop key="viewArticles">displayArticles</prop>

                </props>

            </property>

            <property name="defaultMethodName">

                <value> displayBooks </value>

            </property>

        </bean>

    </property>

</bean>

 

The MethodNameResolver is supposed to resolve method names based on the request coming in. There are three resolvers at your disposal, but of course you can implement more of them yourself if you want to. The explanation from spring official reference is as below

·         ParameterMethodNameResolver – capable of resolving a request parameter and using that as the method name (http://www.sf.net/index.view?testParam=testIt will result in a method testIt(HttpServletRequest, HttpServletResponse) being called). The paramName configuration parameter specifies the parameter that is inspected).

·         InternalPathMethodNameResolver – retrieves the filename from the path and uses that as the method name (http://www.sf.net/testing.view will result in a method testing(HttpServletRequest, HttpServletResponse) being called).

·         PropertiesMethodNameResolver – uses a user-defined properties object with request URLs mapped to methodnames. When the properties contain /index/welcome.html=doIt and a request to /index/welcome.html comes in, the doIt(HttpServletRequest, HttpServletResponse) method is called. This method name resolver works with the PathMatcher, so if the properties contained /**/welcom?.html, it would also have worked!

The preceding example applied ParameterMethodNameResolver. In practice, when my controller called it will check the reqest url. If it includes the parameter viewBooks, then displayBooks() method will be called; If viewArticles is included, then displayArticles() will be called; If neither is included, the default (displayBook()) will be called.

 

public class SpecialReportsController extends MultiActionController {

public ModelAndView displayBooks (HttpServletRequest request, HttpServletResponse response) throws Exception {

                this.commonFunction();

return new ModelAndView(“book.jsp”);

                }

public ModelAndView displayArticles (HttpServletRequest request, HttpServletResponse response) throws Exception {

                this.commonFunction();

                                 return new ModelAndView(“article.jsp”);

                }

 

                private void commonFunction(){

                                …..

}

}

 

Reference:

http://static.springframework.org/spring/docs/1.2.9/reference/mvc.html

http://blog.csdn.net/xxxatt/archive/2007/09/11/1781025.aspx 

 

Advertisements
This entry was posted in Spring. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s