SpringMVC 視圖解析器

前言

?? 在前一篇博客中講了 SpringMVC 的Controller 控制器 ，在這篇博客中將接著介紹一下 SpringMVC 視圖解析器。當我們對SpringMVC控制的資源發(fā)起請求時，這些請求都會被SpringMVC的DispatcherServlet處理，接著Spring會分析看哪一個HandlerMapping定義的所有請求映射中存在對該請求的最合理的映射。然后通過該HandlerMapping取得其對應(yīng)的Handler，接著再通過相應(yīng)的HandlerAdapter處理該Handler。HandlerAdapter在對Handler進行處理之后會返回一個ModelAndView對象。在獲得了ModelAndView對象之后，Spring就需要把該View渲染給用戶，即返回給瀏覽器。在這個渲染的過程中，發(fā)揮作用的就是ViewResolver和View。當Handler返回的ModelAndView中不包含真正的視圖，只返回一個邏輯視圖名稱的時候，ViewResolver就會把該邏輯視圖名稱解析為真正的視圖View對象。View是真正進行視圖渲染，把結(jié)果返回給瀏覽器的。

ViewResolver 和 View 介紹

SpringMVC 用于處理視圖最重要的兩個接口是 ViewResolver 和 View 。 ViewResolver 的主要作用是把一個邏輯上的視圖名稱解析為一個真正的視圖， SpringMVC 中用于把 View 對象呈現(xiàn)給客戶端的是 View 對象本身，而 ViewResolver 只是把邏輯視圖名稱解析為對象的 View 對象。 View 接口的主要作用是用于處理視圖，然后返回給客戶端。

Spring 為我們提供了非常多的視圖解析器，下面將列舉一些視圖解析器。

AbstractCachingViewResolver ： 這是一個抽象類，這種視圖解析器會把它曾經(jīng)解析過的視圖保存起來，然后每次要解析視圖的時候先從緩存里面找，如果找到了對應(yīng)的視圖就直接返回，如果沒有就創(chuàng)建一個新的視圖對象，然后把它放到一個用于緩存的 map 中，接著再把新建的視圖返回。使用這種視圖緩存的方式可以把解析視圖的性能問題降到最低。

UrlBasedViewResolver ： 它是對 ViewResolver 的一種簡單實現(xiàn)，而且繼承了 AbstractCachingViewResolver ，主要就是提供的一種拼接 URL 的方式來解析視圖，它可以讓我們通過 prefix 屬性指定一個指定的前綴，通過 suffix 屬性指定一個指定的后綴，然后把返回的邏輯視圖名稱加上指定的前綴和后綴就是指定的視圖 URL 了。如 prefix=/WEB-INF/jsps/ ， suffix=.jsp ，返回的視圖名稱 viewName=test/indx ，則 UrlBasedViewResolver 解析出來的視圖 URL 就是 /WEB-INF/jsps/test/index.jsp 。默認的 prefix 和 suffix 都是空串。 URLBasedViewResolver 支持返回的視圖名稱中包含 redirect: 前綴，這樣就可以支持 URL 在客戶端的跳轉(zhuǎn)，如當返回的視圖名稱是 ”redirect:test.do” 的時候， URLBasedViewResolver 發(fā)現(xiàn)返回的視圖名稱包含 ”redirect:” 前綴，于是把返回的視圖名稱前綴 ”redirect:” 去掉，取后面的 test.do 組成一個 RedirectView ， RedirectView 中將把請求返回的模型屬性組合成查詢參數(shù)的形式組合到 redirect 的 URL 后面，然后調(diào)用 HttpServletResponse 對象的 sendRedirect 方法進行重定向。同樣 URLBasedViewResolver 還支持 forword: 前綴，對于視圖名稱中包含 forword: 前綴的視圖名稱將會被封裝成一個 InternalResourceView 對象，然后在服務(wù)器端利用 RequestDispatcher 的 forword 方式跳轉(zhuǎn)到指定的地址。使用 UrlBasedViewResolver 的時候必須指定屬性 viewClass ，表示解析成哪種視圖，一般使用較多的就是 InternalResourceView ，利用它來展現(xiàn) jsp ，但是當我們使用 JSTL 的時候我們必須使用 JstlView 。下面是一段 UrlBasedViewResolver 的定義，根據(jù)該定義，當返回的邏輯視圖名稱是 test 的時候， UrlBasedViewResolver 將把邏輯視圖名稱加上定義好的前綴和后綴，即“ /WEB-INF/test.jsp ”，然后新建一個 viewClass 屬性指定的視圖類型予以返回，即返回一個 url 為“ /WEB-INF/test.jsp ”的 InternalResourceView 對象。

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

?

InternalResourceViewResolver ： 它是 URLBasedViewResolver 的子類，所以 URLBasedViewResolver 支持的特性它都支持。在實際應(yīng)用中 InternalResourceViewResolver 也是使用的最廣泛的一個視圖解析器。那么 InternalResourceViewResolver 有什么自己獨有的特性呢？單從字面意思來看，我們可以把 InternalResourceViewResolver 解釋為內(nèi)部資源視圖解析器，這就是 InternalResourceViewResolver 的一個特性。 InternalResourceViewResolver 會把返回的視圖名稱都解析為 InternalResourceView 對象， InternalResourceView 會把 Controller 處理器方法返回的模型屬性都存放到對應(yīng)的 request 屬性中，然后通過 RequestDispatcher 在服務(wù)器端把請求 forword 重定向到目標 URL 。比如在 InternalResourceViewResolver 中定義了 prefix=/WEB-INF/ ， suffix=.jsp ，然后請求的 Controller 處理器方法返回的視圖名稱為 test ，那么這個時候 InternalResourceViewResolver 就會把 test 解析為一個 InternalResourceView 對象，先把返回的模型屬性都存放到對應(yīng)的 HttpServletRequest 屬性中，然后利用 RequestDispatcher 在服務(wù)器端把請求 forword 到 /WEB-INF/test.jsp 。這就是 InternalResourceViewResolver 一個非常重要的特性，我們都知道存放在 /WEB-INF/ 下面的內(nèi)容是不能直接通過 request 請求的方式請求到的，為了安全性考慮，我們通常會把 jsp 文件放在 WEB-INF 目錄下，而 InternalResourceView 在服務(wù)器端跳轉(zhuǎn)的方式可以很好的解決這個 問題。下面是一個 InternalResourceViewResolver 的定義，根據(jù)該定義當返回的邏輯視圖名稱是 test 的時候， InternalResourceViewResolver 會給它加上定義好的前綴和后綴，組成“ /WEB-INF/test.jsp ”的形式，然后把它當做一個 InternalResourceView 的 url 新建一個 InternalResourceView 對象返回。

          <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
       <property name="prefix" value="/WEB-INF/"/>
       <property name="suffix" value=".jsp"></property>
    </bean>
    

?

XmlViewResolver ： 它繼承自 AbstractCachingViewResolver 抽象類，所以它也是支持視圖緩存的。 XmlViewResolver 需要給定一個 xml 配置文件，該文件將使用和 Spring 的 bean 工廠配置文件一樣的 DTD 定義，所以其實該文件就是用來定義視圖的 bean 對象的。在該文件中定義的每一個視圖的 bean 對象都給定一個名字，然后 XmlViewResolver 將根據(jù) Controller 處理器方法返回的邏輯視圖名稱到 XmlViewResolver 指定的配置文件中尋找對應(yīng)名稱的視圖 bean 用于處理視圖。該配置文件默認是 /WEB-INF/views.xml 文件，如果不使用默認值的時候可以在 XmlViewResolver 的 location 屬性中指定它的位置。 XmlViewResolver 還實現(xiàn)了 Ordered 接口，因此我們可以通過其 order 屬性來指定在 ViewResolver 鏈中它所處的位置， order 的值越小優(yōu)先級越高。以下是使用 XmlViewResolver 的一個示例：

（ 1 ）在 SpringMVC 的配置文件中加入 XmlViewResolver 的 bean 定義。使用 location 屬性指定其配置文件所在的位置， order 屬性指定當有多個 ViewResolver 的時候其處理視圖的優(yōu)先級。關(guān)于 ViewResolver 鏈的問題將在后續(xù)內(nèi)容中講到。

          <bean class="org.springframework.web.servlet.view.XmlViewResolver">
       <property name="location" value="/WEB-INF/views.xml"/>
       <property name="order" value="1"/>
    </bean>
    

?

（ 2 ） 在 XmlViewResolver 對應(yīng)的配置文件中配置好所需要的視圖定義。在下面的代碼中我們就配置了一個名為 internalResource 的 InternalResourceView ，其 url 屬性為“ /index.jsp ”。

      <?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
     http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
    <bean id="internalResource" class="org.springframework.web.servlet.view.InternalResourceView">
       <property name="url" value="/index.jsp"/>
    </bean>
</beans>
    

?

（ 3 ） 定義一個返回的邏輯視圖名稱為在 XmlViewResolver 配置文件中定義的視圖名稱—— internalResource 。

          @RequestMapping("/xmlViewResolver")
    public String testXmlViewResolver() {
       return "internalResource";
    }
    

?

（ 4 ） 這樣當我們訪問到上面定義好的 testXmlViewResolver 處理器方法的時候返回的邏輯視圖名稱為“ internalResource ”，這時候 Spring 就會到定義好的 views.xml 中尋找 id 或 name 為“ internalResource ”的 bean 對象予以返回，這里 Spring 找到的是一個 url 為“ /index.jsp ”的 InternalResourceView 對象。

BeanNameViewResolver ： 這個視圖解析器跟 XmlViewResolver 有點類似，也是通過把返回的邏輯視圖名稱去匹配定義好的視圖 bean 對象。不同點有二，一是 BeanNameViewResolver 要求視圖 bean 對象都定義在 Spring 的 application context 中，而 XmlViewResolver 是在指定的配置文件中尋找視圖 bean 對象，二是 BeanNameViewResolver 不會進行視圖緩存。看一個例子，在 SpringMVC 的配置文件中定義了一個 BeanNameViewResolver 視圖解析器和一個 id 為 test 的 InternalResourceview bean 對象。

          <bean class="org.springframework.web.servlet.view.BeanNameViewResolver">
       <property name="order" value="1"/>
    </bean>

    <bean id="test" class="org.springframework.web.servlet.view.InternalResourceView">
       <property name="url" value="/index.jsp"/>
    </bean>
    

?

這樣當返回的邏輯視圖名稱是 test 的時候，就會解析為上面定義好 id 為 test 的 InternalResourceView 。

ResourceBundleViewResolver ： 它和 XmlViewResolver 一樣，也是繼承自 AbstractCachingViewResolver ，但是它緩存的不是視圖，這個會在后面有說到。和 XmlViewResolver 一樣它也需要有一個配置文件來定義邏輯視圖名稱和真正的 View 對象的對應(yīng)關(guān)系，不同的是 ResourceBundleViewResolver 的配置文件是一個屬性文件，而且必須是放在 classpath 路徑下面的，默認情況下這個配置文件是在 classpath 根目錄下的 views.properties 文件，如果不使用默認值的話，則可以通過屬性 baseName 或 baseNames 來指定。 baseName 只是指定一個基名稱， Spring 會在指定的 classpath 根目錄下尋找以指定的 baseName 開始的屬性文件進行 View 解析，如指定的 baseName 是 base ，那么 base.properties 、 baseabc.properties 等等以 base 開始的屬性文件都會被 Spring 當做 ResourceBundleViewResolver 解析視圖的資源文件。 ResourceBundleViewResolver 使用的屬性配置文件的內(nèi)容類似于這樣：

      resourceBundle.(class)=org.springframework.web.servlet.view.InternalResourceView
resourceBundle.url=/index.jsp
test.(class)=org.springframework.web.servlet.view.InternalResourceView
test.url=/test.jsp
    

?

在這個配置文件中我們定義了兩個 InternalResourceView 對象，一個的名稱是 resourceBundle ，對應(yīng) URL 是 /index.jsp ，另一個名稱是 test ，對應(yīng)的 URL 是 /test.jsp 。從這個定義來看我們可以知道 resourceBundle 是對應(yīng)的視圖名稱，使用 resourceBundle.(class) 來指定它對應(yīng)的視圖類型， resourceBundle.url 指定這個視圖的 url 屬性。會思考的讀者看到這里可能會有這樣一個問題：為什么 resourceBundle 的 class 屬性要用小括號包起來，而它的 url 屬性就不需要呢？這就需要從 ResourceBundleViewResolver 進行視圖解析的方法來說了。 ResourceBundleViewResolver 還是通過 bean 工廠來獲得對應(yīng)視圖名稱的視圖 bean 對象來解析視圖的。那么這些 bean 從哪里來呢？就是從我們定義的 properties 屬性文件中來。在 ResourceBundleViewResolver 第一次進行視圖解析的時候會先 new 一個 BeanFactory 對象，然后把 properties 文件中定義好的屬性按照它自身的規(guī)則生成一個個的 bean 對象注冊到該 BeanFactory 中，之后會把該 BeanFactory 對象保存起來，所以 ResourceBundleViewResolver 緩存的是 BeanFactory ，而不是直接的緩存從 BeanFactory 中取出的視圖 bean 。然后會從 bean 工廠中取出名稱為邏輯視圖名稱的視圖 bean 進行返回。接下來就講講 Spring 通過 properties 文件生成 bean 的規(guī)則。它會把 properties 文件中定義的屬性名稱按最后一個點“ . ”進行分割，把點前面的內(nèi)容當做是 bean 名稱，點后面的內(nèi)容當做是 bean 的屬性。這其中有幾個特別的屬性， Spring 把它們用小括號包起來了，這些特殊的屬性一般是對應(yīng)的 attribute ，但不是 bean 對象所有的 attribute 都可以這樣用。其中 (class) 是一個，除了 (class) 之外，還有 (scope) 、 (parent) 、 (abstract) 、 (lazy-init) 。而除了這些特殊的屬性之外的其他屬性， Spring 會把它們當做 bean 對象的一般屬性進行處理，就是 bean 對象對應(yīng)的 property 。所以根據(jù)上面的屬性配置文件將生成如下兩個 bean 對象：

          <bean id="resourceBundle" class="org.springframework.web.servlet.view.InternalResourceView">
       <property name="url" value="/index.jsp"/>
    </bean>

    <bean id="test" class="org.springframework.web.servlet.view.InternalResourceView">
       <property name="url" value="/test.jsp"/>
    </bean>
    

?

從 ResourceBundleViewResolver 使用的配置文件我們可以看出，它和 XmlViewResolver 一樣可以解析多種不同類型的 View ，因為它們的 View 是通過配置的方式指定的，這也就意味著我們可以指定 A 視圖是 InternalResourceView ， B 視圖是 JstlView 。

來看下面這個一個例子，我在 SpringMVC 的配置文件中定義了一個 ResourceBundleViewResolver 對象，指定其 baseName 為 views ，然后 order 為 1 。

          <bean class="org.springframework.web.servlet.view.ResourceBundleViewResolver">
       <property name="basename" value="views"/>
       <property name="order" value="1"/>
    </bean>
    

?

我在 classpath 的根目錄下有兩個屬性文件，一個是 views.properties ，一個是 views_abc.properties ，它們的內(nèi)容分別如下：

views.properties ：

      resourceBundle.(class)=org.springframework.web.servlet.view.InternalResourceView
resourceBundle.url=/index.jsp
test.(class)=org.springframework.web.servlet.view.InternalResourceView
test.url=/test.jsp
    

?

views_abc.properties ：

      abc.(class)=org.springframework.web.servlet.view.InternalResourceView
abc.url=/abc.jsp
    

?

定義了如下這樣一個 Controller ，它有三個處理器方法。

      @Controller
@RequestMapping("/mytest")
public class MyController {
    @RequestMapping("resourceBundle")
    public String resourceBundle() {
       return "resourceBundle";
    }

    @RequestMapping("testResourceBundle")
    public String testResourceBundle() {
       return "test";
    }

    @RequestMapping("abc")
    public String abc() {
       return "abc";
    }

}
    

?

那么當我們請求 /mytest/resourceBundle.do 的時候， ResourceBundleViewResolver 會首先嘗試著來解析該視圖，這里 Controller 處理器方法返回的邏輯視圖名稱是 resourceBundle ， ResourceBundleViewResolver 按照上面提到的解析方法進行解析，這個時候它發(fā)現(xiàn)它是可以解析的，然后就返回了一個 url 為 /index.jsp 的 InternalResourceView 對象。同樣，請求 /mytest/testResourceBundle.do 返回的邏輯視圖 test 和 /mytest/abc.do 返回的邏輯視圖 abc 它都可以解析。當我們把 basename 指定為包的形式，如“ com.tiantian.views ”，的時候 Spring 會按照點“ . ”劃分為目錄的形式，到 classpath 相應(yīng)目錄下去尋找 basename 開始的配置文件，如上面我們指定 basename 為“ com.tiantian.views ”，那么 spring 就會到 classpath 下的 com/tiantian 目錄下尋找文件名以 views 開始的 properties 文件作為解析視圖的配置文件。

FreeMarkerViewResolver 、 VolocityViewResolver ： 這兩個視圖解析器都是 UrlBasedViewResolver 的子類。 FreeMarkerViewResolver 會把 Controller 處理方法返回的邏輯視圖解析為 FreeMarkerView ，而 VolocityViewResolver 會把返回的邏輯視圖解析為 VolocityView 。因為這兩個視圖解析器類似，所以這里我就只挑 FreeMarkerViewResolver 來做一個簡單的講解。 FreeMarkerViewResolver 和 VilocityViewResolver 都繼承了 UrlBasedViewResolver 。

對于 FreeMarkerViewResolver 而言，它會按照 UrlBasedViewResolver 拼接 URL 的方式進行視圖路徑的解析。但是使用 FreeMarkerViewResolver 的時候不需要我們指定其 viewClass ，因為 FreeMarkerViewResolver 中已經(jīng)把 viewClass 定死為 FreeMarkerView 了。

我們先在 SpringMVC 的配置文件里面定義一個 FreeMarkerViewResolver 視圖解析器，并定義其解析視圖的 order 順序為 1 。

          <bean class="org.springframework.web.servlet.view.freemarker.FreeMarkerViewResolver">
       <property name="prefix" value="fm_"/>
       <property name="suffix" value=".ftl"/>
       <property name="order" value="1"/>
    </bean>
    

?

那么當我們請求的處理器方法返回一個邏輯視圖名稱 viewName 的時候，就會被該視圖處理器加上前后綴解析為一個 url 為“ fm_viewName.ftl ”的 FreeMarkerView 對象。對于 FreeMarkerView 我們需要給定一個 FreeMarkerConfig 的 bean 對象來定義 FreeMarker 的配置信息。 FreeMarkerConfig 是一個接口， Spring 已經(jīng)為我們提供了一個實現(xiàn)，它就是 FreeMarkerConfigurer 。我們可以通過在 SpringMVC 的配置文件里面定義該 bean 對象來定義 FreeMarker 的配置信息，該配置信息將會在 FreeMarkerView 進行渲染的時候使用到。對于 FreeMarkerConfigurer 而言，我們最簡單的配置就是配置一個 templateLoaderPath ，告訴 Spring 應(yīng)該到哪里尋找 FreeMarker 的模板文件。這個 templateLoaderPath 也支持使用“ classpath: ”和“ file: ”前綴。當 FreeMarker 的模板文件放在多個不同的路徑下面的時候，我們可以使用 templateLoaderPaths 屬性來指定多個路徑。在這里我們指定模板文件是放在“ /WEB-INF/freemarker/template ”下面的。

          <bean class="org.springframework.web.servlet.view.freemarker.FreeMarkerConfigurer">
       <property name="templateLoaderPath" value="/WEB-INF/freemarker/template"/>
    </bean>
    

?

接下來我們定義如下一個 Controller ：

      @Controller
@RequestMapping("/mytest")
public class MyController {

    @RequestMapping("freemarker")
    public ModelAndView freemarker() {
       ModelAndView mav = new ModelAndView();
       mav.addObject("hello", "andy");
       mav.setViewName("freemarker");
       return mav;
    }

}
    

?

由上面的定義我們可以看到這個 Controller 的處理器方法 freemarker 返回的邏輯視圖名稱是“ freemarker ”。那么如果我們需要把該 freemarker 視圖交給 FreeMarkerViewResolver 來解析的話，我們就需要根據(jù)上面的定義，在模板路徑下定義視圖對應(yīng)的模板，即在“ /WEB-INF/freemarker/template ”目錄下建立 fm_freemarker.ftl 模板文件。這里我們定義其內(nèi)容如下：

      <html>
    <head>
       <title>FreeMarker</title>
    </head>
    <body>
       <b>Hello World</b>
       <font color="red">Hello World!</font>
       ${hello}
    </body>
</html>
    

?

經(jīng)過上面的定義當我們訪問 /mytest/freemarker.do 的時候就會返回一個邏輯視圖名稱為“ freemarker ”的 ModelAndView 對象，根據(jù)定義好的視圖解析的順序，首先進行視圖解析的是 FreeMarkerViewResolver ，這個時候 FreeMarkerViewResolver 會試著解析該視圖，根據(jù)它自身的定義，它會先解析到該視圖的 URL 為 fm_freemarker.ftl ，然后它會看是否能夠?qū)嵗撘晥D對象，即在定義好的模板路徑下是否有該模板存在，如果有則返回該模板對應(yīng)的 FreeMarkerView 。在這里的話 /WEB-INF/freemarker/template 目錄下是存在模板文件 fm_freemarker.ftl 的，所以會返回一個 url 為 fm_freemarker.ftl 的 FreeMarkerView 對象。接著 FreeMarkerView 就可以利用該模板文件進行視圖的渲染了。所以訪問結(jié)果應(yīng)該如下所示：

?

?

視圖解析器鏈

?????? 在 SpringMVC 中可以同時定義多個 ViewResolver 視圖解析器，然后它們會組成一個 ViewResolver 鏈。當 Controller 處理器方法返回一個邏輯視圖名稱后， ViewResolver 鏈將根據(jù)其中 ViewResolver 的優(yōu)先級來進行處理。所有的 ViewResolver 都實現(xiàn)了 Ordered 接口，在 Spring 中實現(xiàn)了這個接口的類都是可以排序的。在 ViewResolver 中是通過 order 屬性來指定順序的，默認都是最大值。所以我們可以通過指定 ViewResolver 的 order 屬性來實現(xiàn) ViewResolver 的優(yōu)先級， order 屬性是 Integer 類型， order 越小，對應(yīng)的 ViewResolver 將有越高的解析視圖的權(quán)利，所以第一個進行解析的將是 ViewResolver 鏈中 order 值最小的那個。當一個 ViewResolver 在進行視圖解析后返回的 View 對象是 null 的話就表示該 ViewResolver 不能解析該視圖，這個時候如果還存在其他 order 值比它大的 ViewResolver 就會調(diào)用剩余的 ViewResolver 中的 order 值最小的那個來解析該視圖，依此類推。當 ViewResolver 在進行視圖解析后返回的是一個非空的 View 對象的時候，就表示該 ViewResolver 能夠解析該視圖，那么視圖解析這一步就完成了，后續(xù)的 ViewResolver 將不會再用來解析該視圖。當定義的所有 ViewResolver 都不能解析該視圖的時候， Spring 就會拋出一個異常。

?????? 基于 Spring 支持的這種 ViewResolver 鏈模式，我們就可以在 SpringMVC 應(yīng)用中同時定義多個 ViewResolver ，給定不同的 order 值，這樣我們就可以對特定的視圖特定處理，以此來支持同一應(yīng)用中有多種視圖類型。注意：像 InternalResourceViewResolver 這種能解析所有的視圖，即永遠能返回一個非空 View 對象的 ViewResolver 一定要把它放在 ViewResolver 鏈的最后面。

?

          <bean class="org.springframework.web.servlet.view.XmlViewResolver">
       <property name="location" value="/WEB-INF/views.xml"/>
       <property name="order" value="1"/>
    </bean>

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

?