spring Resolving views

All MVC frameworks for web applications provide a way to address vies. Spring provides view resolvers, which enable you to render models in a browser without tying you t a specific view technology.Out of the box, Spring enables you to use JSPs,Velocity templates and XSLT views,for example.See Chapter 22,View technologies for a discusstion of how to integrate and use a number of disparate view technologies.
The two interfaces that are important to the way Spring handles views are ViewResolver and View.
The ViewResolver provides a mapping between view names and actual view.The view interface addresses the preparation of the request and hand the request over to one of the view technolgies.

Resolving views with the ViewResolver interface

As discussed in Section 21.3,”Implementing Controllers”,all handler methods in the Spring Web MVC controllers must resolve to a logical view name, either explicity(e.g., by returning a String,View,or ModelAndView)or implicityly(i.e.,based on convetions).Views in Spring are addressed by a logical view name and are resolved by a view resolver.Spring comes with quite a few view resolvers.This table lists most of them; a couple of examples follows.

ViewResolver	Description
AbstractCachingViewResolver	Abstract view resolver that caches views.Often views need preparation before they can be used; extending this view resolver provides caching
XmlViewResolver	Implementation of ViewResolver that accepts a configuration file written in XML with the same DTD as Spring’s XML bean factories.The default configuration file is /WEB-INF/views.xml
ResourceBundleViewResolver	Implementation of ViewResolver that uses bean definitions in a ResourceBundle,specified by the bundle base name.Typically you dfine the bundle in a properties file,located in the classpath.The default file name is views.properties.
ContentNegotiatingViewResolver	Implementation of the ViewResolver interface that resolves a view based on the request file name or Accept header.See the section called “ContentNegotiatingViewResolver”.

As an example, with JSP as a view technology,you can use the UrlBasedViewResolver.This view resolver translates a view name to a URL and hands the request over to the RequestDispatcher to render the view.

<bean id="viewResolver" class="org.springframework.web.servlet.view.UrlBasedViewResolver">
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/>
<property name="prefix" value="/WEB-INF/jsp/"/>
<property name="suffix" value=".jsp"/>
</bean>

When return test as a logical view name,this view resolver forwards the request to the RequestDispatcher that will send the request to /WEB-INF/jsp/test.jsp.
When you combine different view technologies in a web application, you can use the ResourceBundleViewResolver:

<bean id="viewResolver" class="org.springframework.web.servlet.view.ResourceBundleViewResolver">
<property name="basename" value="views"/>
<property name="defaultParentView" value="parentView"/>

The ResourceBundleViewResolver inspects the ResourceBundle identified by the basename,and for each view it is supposed to resolve, it uses the value of the property [viewname].url as the view class and the value of the property[viewname].url as the view url.Examples can identify a parent view, from which all views in the properties file “extend”.This way you can specify a default view class, for example.

Note

Subclasses of AbstractCachingViewResolver cache view instances that they resolve.Caching improves performance of certain view technologies.It’s possible to turn off the cache by setting the cache property to false.Furthemore,if you must fefresh a certain view at runtime.

Chaining ViewResolvers

Spring supports multiple view resolvers.Thus you can chain resolvers and, for example,override specific views in certain circumstances.You chain view resolvers by adding more than one resolver to your application context and, if necessary,by setting the order property to specify ordering.Remember,the higher the order property,the later the view resolver is positioned in the chain.
In the following example,the chain of view resolvers consists of two resolvers, an InteranlResourceViewResolver, which is always automatically positioned as the last resolver in the chain, and an XmlViewResolver for specifying Excel views.Excel views are not supported by the InternalResourceViewResolver.

If a specific view resolver does not result in a view,Spring examines the context for other view resolvers.If additional view resolvers exist,Spring continues to inspect them until a view is resolved.If no view resolver returns a view,Spring throws a ServletException.

The contact of a view resolver specifies that a view resolver can return null to indicate the view could not be found.Not all view resolvers do this,however,because in some cases, the resolver simply cannot detect whether or not the view exists.For example,

这是上面关于ViewResolver的介绍，其中我们比较常用到的就是ContentNegotiatingViewResolver。
它处理视图是根据请求的文件名，或者请求当中的Accept header里映射视图的。

ContentNegotiatingViewResolver

The ContentNegotiatingViewResolver does not resolve views itself but rather delegates to other view resolvers,selecting the view that resembles the representation requested by the client.Two strategies exist for a client to request a representation from the server:
- Use a distinct URI for each resource,typically by using a different file extension in the URI. For example,the URI http://www.example.com/users/fred.pdf request a PDF representation of the user fred,and http://www.example.com/users/fred.xml requests an XML representation.
- Use the same URI for the client to locate the resource,but set the Accept HTTP request header to list the media types that it understands.For example, an HTTP request for http://www.example./users/fred with an Accept header set to application/pdf requests a PDF representation of the user fred,while http://www.example.com/users/fred with an Accept header set to text/xml requests an XML representation. This strategy is known as contentnegotiation.
ContentNegotiatingViewResolver并不处理任何视图，而是将处理工作委托给其他视图处理器，或者通过客户端的Accept请求头来决定视图。一般情况下有以下两种请求视图的方式。
通过唯一URI，uri中包含具体的文件类型。
另一种是使用相同的uri，但是通过Accept请求头来判断具体的请求类型。

Note

One issue with the Accept header is that it is impossible to set it in a web browser within HTML.
For example, in Firefox, it is fixed to:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

For this reason it is common to see the use of a distinct URI for each representation when developing browser based web applications.
但是有些浏览器请求html的时候，Accept请求头会加上一系列匹配类型,基于上述原因，在开发web应用的时候会使用唯一URI。

To support multiple representations of a resource, Spring provides the ContentNegotiatingViewResolver to resolve a view based on the file extension or Accept header of the HTTP request.ContentNegotiatingViewResolver does not perform the view resolution itself but instead delegates to a list of view resolvers that you specify throught the bean property ViewResolvers.
为了支持各种不同类型的文件请求，Spring通过ContentNegotiatingViewResolver来解决基于扩展名或者http请求Accept头部类型的文件。它本身并不处理请求，而是将请求的处理，代理给一系列ViewResolvers.

To support custom resolution of a view based on a file extension, use a ContentNegotiationManager: see the section called “Content Negotiation”.
Here is an example configuration of a ContentNegotiatingViewResolver:

<bean class="org.springframework.web.servlet.view.ContentNegotiatingViewResolver">
    <property name="viewResolvers">
        <bean class="org.springframework.web.servlet.view.BeanNameViewResolver"/>
        <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
            <property name="prefix" value="/WEB-INF/jsp/"/>
            <property name="suffix" value=".jsp"/>
        </bean>
    </property>
    <property name="defaultViews">
        <list>
            <bean class="org.springframework.web.servlet.view.json.MappingJackson2JsonView"/>
        </list>
    </property>
</bean>
<bean id="content" class="com.foo.samples.rest.SampleContentAtomView"/>

The InteranlResourceViewResolver handles the translation of view names and JSP pages,while the BeanNameViewResolver returns a view based on the name of a bean.(See “Resolving views with the ViewResolver interface” for more details on how Spring looks up and instantiates a View.)In this example,the content bean is a class that inherits from AbstractAtomFeedView, which returns an Atom RSS feed.For more information on creating an Atom Feed repressentation,see the section Atom Views.

In the above configuration, if a request is made with an .html extension, the view resolver looks for a view that matches the text/html media type.The InternalResourceViewResolver provides the matching view for text/html.If the refquest is made with the file extension .atom, the view resolver looks for a view that matches the application/atom+xml mediat type.This view is provided by the BeanNameViewResolver that maps to the SampleContentAtomView if the view name returned is content.If the request is made with the file extension .json,the MappingJackson2JsonView instance from the DefaultViews list will be selected regardless of the view name.Alternatively,client requests can be made without a file extension but with the Accept header set to the preferred media-type, and the same resolution of request to views would occur.
通过上面的配置，如果一个请求以.html为扩展名，viewresolver就会寻找寻找关联text/html类型的视图。InternalResourceViewResolver提供匹配text/html类型的视图。如果一个请求一个.atom结尾，viewresolver就会寻找application/atom+xml类型的视图。这种视图由BeanNameViewResolver提供，如果视图名称是content,那么视图就会映射到SampleContentAtomView.

Note

if ContentNegotiatingViewResolver’s list of ViewResolvers is not configured explicitly,it automatically uses any ViewResolvers defined in the application context.