Spring3.X @MVC - （七）Spring中强大的内容协商视图解析器

前言：

一、总共有10节，也就是10篇博客来讲述Spring的MVC，几乎涵盖了所有Spring MVC中的内容。

 

二、我创建的例子是一个球场预订系统，例子我已经测试调试通过，是一个Maven的project，包含一个Parent project:wsheng-spring-base和一个子Module：wsheng-spring-mvc.

 

三、在Eclipse中直接import maven的project即可，会同时引入上诉两个project的。

 

四、如果你没有耐心，可以不必往下学习，因为网上有很多例子，但是都是讲的Spring MVC很少的面，而且你可以快速的上手，但如果你想真正了解Spring MVC中的很多细节，就可以慢慢的去看博客（从第一节到第十节），如果有什么问题，欢迎信息告诉我。

 

五、学习的方法是你可以先将源码导入到eclipse中，然后根据博客上的内容，对照源码，慢慢消化，这是个漫长的过程，但是会帮助你了解很多Spring MVC的细节。

===================================================================================

 

 

在Spring3.X @MVC - （六）按照返回的名称解析视图 - Spring MVC中强大的视图解析器的基础上

http://josh-persistence.iteye.com/blog/1884194 

进一步的讨论和学习Spring中最为强大的视图解析器： Spring的视图和内容协商机制。

 

1. 问题：

如果在在控制器中只是返回一个没有扩展名的URL，如welcome，希望设计一个策略：根据具体的请求返回对应的视图：welcome.html或者是welcome.pdf。

 

2.解决方案：

当web应用接受一个请求时，请求包含一系列的属性，让Sping MVC能够确定返回给请求方的正确的内容和类型。主要的两个属性包括：

1） 请求中的URL的扩展名。

2） HTTP Accept头标。

例如，如果一个url的形式为/welcome.xml的请求，Spring MVC的控制器能够检查扩展名并且将其委派给代表XML视图的一个逻辑视图。

         但是如果请求的形式不再是/welcome.xml，而是welcome。这个请求应该委派给一个XML还是一个HTML视图呢？还是一个PDF视图呢？此时通过URL无从知晓。这种情况下的解决方案

         A：使用默认的视图：如welcome.html

         B：检查请求的HTTP Accept头标来决定哪种视图更加合适。

然而在Spring MVC的控制器中检查HTTP Accept头标可能是个棘手的问题，所以在Sping MVC中专门通过ContentNegotiatingViewResolver解析器支持头标的检查，使视图委派可以根据URL文件扩展名或者HTTP Accept头标值指出。

 

3. 工作原理：

Sping MVC内容协商解析器基于ContentNegotiationVIewResolver类。下面先介绍下其怎样和其它解析器集成的。

<!-- View resolvers --> 

    <!-- View exception resolver -->

 

    <bean

        class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">

        <property name="exceptionMappings">

            <props>

                <prop

                    key="com.wsheng.spring.service.ReservationNotAvailableException">

                    reservationNotAvailable

                </prop>

                <prop

                    key="com.wsheng.spring.web.ReservationWebException">

                    reservationWebException

                </prop>

<!-- Define catch all class or property defaultErrorView -->

<!-- <prop key="java.lang.Exception">error</prop>-->

            </props>

        </property>

       <property name="defaultErrorView" value="error"/>

 

    </bean> 

 

<!--     Views mapped in views.properties (PDF, XLS classes, and others)  -->

    <bean id="contentNegotiatingResolver"

              class="org.springframework.web.servlet.view.ContentNegotiatingViewResolver">

        <property name="order"

                  value="#{T(org.springframework.core.Ordered).HIGHEST_PRECEDENCE}" />

         <property name="mediaTypes">

            <map>

                  <entry key="html" value="text/html"/>

                  <entry key="pdf" value="application/pdf"/>

                  <entry key="xsl" value="application/vnd.ms-excel"/>

                  <entry key="xml" value="application/xml"/>

                  <entry key="json" value="application/json"/>

            </map>

        </property>

     </bean>

 

    <bean id="resourceBundleResolver"

        class="org.springframework.web.servlet.view.ResourceBundleViewResolver">

        <property name="basename" value="views" />

        <property name="order" value="#{contentNegotiatingResolver.order+1}" />

    </bean>

 

    <bean id="secondaryResourceBundleResolver"

        class="org.springframework.web.servlet.view.ResourceBundleViewResolver">

        <property name="basename" value="secondaryviews" />

        <property name="order" value="#{resourceBundleResolver.order+1}" />

    </bean>

 

    <!-- Views mapped in JSPs under /WEB-INF/jsp --> 

 

    <bean id="internalResourceResolver"

        class="org.springframework.web.servlet.view.InternalResourceViewResolver">

        <property name="prefix" value="/WEB-INF/jsp/" />

        <property name="suffix" value=".jsp" />

    <property name="order" value="#{secondaryResourceBundleResolver.order+1}" />

 

    </bean>

 

1） 你可能发现了，这个程序清单中的解析器声明和前面的看到的不太相同，因为这里面使用Spring的EL表达式SpEL来指定视图解析器的优先顺序。在这个例子中，ContentNegotiatingViewResolver解析器得到了最高的优先权，它的order根据SpEL申明

#{T(org.springframework.core.Ordered).HIGHEST_PRECEDENCE赋值。后续的解析器Bean使用相似的SpEL声明决定order值----#{bean_name.order+1}.这使你可以使用相对的解析器order权重，代替硬编码值。

       

2） 观察ContentNegotiatingViewResolver解析器的配置，这个配置设置该解析器为所有解析器中的最高优先级别，这种设置其实是有必要的，也就是说，基本上来说，内容协商解析器的优先级应该是最高的。那么为什么内容协商解析器ContentNegotiatinViewResolver要具有最高的优先级呢？原因是该解析器其实不会解析视图，而是将它们委派给其他的视图解析器。看一个例子：

         我们假定Sping MVC的控制器接受/reserverationSummary.xml的请求，一旦处理器方法结束，它将控制器发送给名为reservation的逻辑视图。根据前面学的内容可知，当控制器处理结束后，将控制器发送给reservation的逻辑视图后，Spring MVC的解析器开始起作用，因为内容协商处理器的优先级最高，所以开始作用的就是ContentNegotiationViewResolver解析器。

        ContentNegotiatingViewResolver解析器首先根据如下原则确定请求的媒体类型

A）检查请求扩展名：根据ContentNegotiationViewResolver bean的MediaType段中指定的默认媒体类型（例如text/html)检查请求路径的扩展名(例如.html, .xml或.pdf)

B）进一步确定请求扩展名： 如果请求路径具有扩展名，但是在ContentNegotiatingViewResolver bean默认的mediaTypes段中找不到，就试图使用属于Java Activation Framework的FileTypeMap确定扩展名的媒体类型。

C）如果没有扩展名：如果请求路径中没有扩展名，使用请求的HTTP Accept头标。

      根据上面的A）B） C）的阐述，对于/reservationSummary.xml上的请求，A）中可看出媒体类型为application/xml。但是，对于类似/reservationSummary这样的URL请求，媒体类型在C）之前还没有被确定。其实，HTTP Accept头标中包含类似Accept:text/html或者Accept:application/pdf这样的值，假如请求的URL中不存在扩展名，这些值帮助解析器确定请求者预期的媒体类型。

      此时，ContentNegotiatingViewResolver解析器得到一个媒体类型application/xml和reservation的逻辑视图。根据这两个重要的信息，再其他解析器上进行一次循环（根据解析器的顺序），根据检测到的媒体类型（此处为application.xml）确定哪个视图与逻辑名称最为匹配。

       这个过程可以允许你拥有多个同名的逻辑视图，每个视图支持一种不同的媒体类型（例如HTML，PDF，XLS）,然后由ContentNegotiatingViewResolver来解析最佳匹配。

       这就是ContentNegotiatingViewResolver的好处，它会使控制器的设计进一步简化了，因为再也没有必要用硬编码为某个媒体类型创建特定的逻辑视图（例如pdfReservation, xlsReservation, htmlReservation),而代之以单一的视图(reservation),让ContentNegotiatingViewResolver解析器确定最佳匹配。要么匹配reservation.pdf, reservation.html,reservation.xls,reservation.json，reserveration.jsp等。

即可以省掉很多代码：

model.addAttribute("reservations",reservations);

// Check request extension

/**

if(request.getServletPath().endsWith(".pdf")) { 

   // PDF extension

   // Return view pdfSummary. Via resolver the view

   // is mapped to the class PdfReservationSummary

   // as defined in views.properties

   return "pdfSummary";

} else if(request.getServletPath().endsWith(".xls")) { 

   // Excel extension

   // Return view xlsSummary. Via resolver the view

   // is mapped to the class ExcelReservationSummary

   // as defined in views.properties

   return "excelSummary";

} else { 

   // Any other extension return the file system view reservationSummary

   // Via resolver it will be mapped to /WEB-INF/jsp/reservationSummary.jsp

   return "reservationSummary";

   }*/

return "reservationSummary"; // 只需要这句代码就可。

 

       这个处理过程中，可能的处理过程如下：

A）如果确定媒体类型为application/pdf。如果具有最高优先级的解析器包含有逻辑视图reservation的映射，但是不支持application/pdf类型。那么也就不存在匹配，会继续在剩余的解析器上进心查询匹配。

B）如果确定媒体类型为application/pdf。如果具有最高优先级的解析器包含有逻辑视图reservation的映射，并且这个视图支持application/pdf类型，则匹配该解析器。

C）如果媒体类型确定为text/html，而此时如果有4个名为reservation的逻辑视图，但是如果此时映射到两个具有最高优先级的解析器的视图都不支持text/html。那么就会和剩下的包含reservation视图映射且支持text/html的解析器匹配。

 

        总结：

1） 这个视图搜索过程会在应用中配置的所有解析器上进行。如果你不希望在ContentNegotiatingViewResolver解析器之外进行配置，也可以在ContentNegotiatingViewResolver bean内配置默认视图和解析器。

 

2）很明显使用视图内容协商处理器（ContentNegotiatingViewResolver）后，可以不用每个逻辑视图(a.html, b.pdf, c.xls)以及为同名的逻辑视图(a: a.html, a.pdf, a.xls, a.json)等找一个最佳的匹配。极大的简化了Spring的视图解析器的配置。