前言：
一、总共有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的视图解析器的配置。