一、本来想说的是返回值处理问题,但在 SpringMVC 中,返回值处理问题的核心就是视图渲染。所以这里标题叫视图渲染问题。

本来想在上一篇文章中对视图解析进行说明的,但是通过源码发现,它应该算到视图渲染中,所以在这篇文章中进行说明

org.springframework.web.servlet.DispatcherServlet#doDispatch方法中

mv = ha.handle(processedRequest, response, mappedHandler.getHandler());//945行返回了 ModelAndView 对象

processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);// 959行进行的就是返回值处理问题

org.springframework.web.servlet.DispatcherServlet#processDispatchResult方法中

render(mv, request, response); //1012进行视图的渲染(包含视图解析)

org.springframework.web.servlet.DispatcherServlet#render 方法

protected void render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response) throws Exception {// Determine locale for request and apply it to the response.Locale locale = this.localeResolver.resolveLocale(request);response.setLocale(locale);View view;if (mv.isReference()) {// We need to resolve the view name.view = resolveViewName(mv.getViewName(), mv.getModelInternal(), locale, request);if (view == null) {throw new ServletException("Could not resolve view with name '" + mv.getViewName() + "' in servlet with name '" +getServletName() + "'");}}else {// No need to lookup: the ModelAndView object contains the actual View object.view = mv.getView();if (view == null) {throw new ServletException("ModelAndView [" + mv + "] neither contains a view name nor a " +"View object in servlet with name '" + getServletName() + "'");}}// Delegate to the View object for rendering.if (logger.isDebugEnabled()) {logger.debug("Rendering view [" + view + "] in DispatcherServlet with name '" + getServletName() + "'");}try {view.render(mv.getModelInternal(), request, response);}catch (Exception ex) {if (logger.isDebugEnabled()) {logger.debug("Error rendering view [" + view + "] in DispatcherServlet with name '"+ getServletName() + "'", ex);}throw ex;}}

可以看到有两个 if ,第一个 if 解决的是视图解析问题,第二个 if 解决的是视图渲染问题。还有官方是这样描述这个方法的:Render the given ModelAndView.

二、视图解析:通过视图解析器进行视图的解析

1.解析一个视图名到一个视图对象,具体解析的过程是:在容器中查找所有配置好的视图解析器(List类型),然后进行遍历,

只要有一个视图解析器能解析出视图就返回 View 对象,若遍历完成后都不能解析出视图,那么返回 null。

具体来看:

org.springframework.web.servlet.DispatcherServlet#resolveViewName

protected View resolveViewName(String viewName, Map<String, Object> model, Locale locale,HttpServletRequest request) throws Exception {  for (ViewResolver viewResolver : this.viewResolvers) {View view = viewResolver.resolveViewName(viewName, locale);
    if (view != null) {
      return view;}}
  return null;
}

2. ViewResolver

(1)官方描述:

* Interface to be implemented by objects that can resolve views by name.
*
* <p>View state doesn't change during the running of the application,
* so implementations are free to cache views.
*
* <p>Implementations are encouraged to support internationalization,
* i.e. localized view resolution.

说明:

ViewResolver 接口由能解析视图名称的实现类来实现。

在程序运行期间视图的状态不能更改,所以实现能被随意缓存。鼓励实现支持国际化。

(2)ViewResolver 的整个体系

可以看出 SpringMVC 提供了很多类型视图解析器。

(3)在 SpringMVC 的第一篇文章中,配置过一个视图解析器。

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

发送一个请求之后,发现要遍历的 ViewResolvers 只有一个,就是上面的这个 ViewResolver。没有其他默认的视图解析器。所以说在SpringMVC 配置文件中,必须配置至少一个 视图解析器。

那么这里会有一个问题?如果配置多个视图解析器,他们的遍历顺序是怎么样的呢?

ViewResolver 的所有实现类中都存在一个 order 属性。

看这个属性的 setOrder() 注释:Set the order in which this {@link org.springframework.web.servlet.ViewResolver} is evaluated。设置谁先被评估。

还有一点小不同:

除 ContentNegotiatingViewResolver 之外,其他所有的 ViewResolver 的默认值都是:Integer.MAX_VALUE(2^31 -1,即2147483647),

而 ContentNegotiatingViewResolver 的默认值为 Ordered.HIGHEST_PRECEDENCE(-2147483648)。

那他们的遍历的顺序与 order 是什么关系呢?如果不设置 order 的话,遍历顺序又是怎么样的?

<1>设置 order 属性后,遍历顺序是怎么样的

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

对 BeanNameViewResolver 的 order 属性指定为 99,对 InternalResourceViewResolver 指定为-99。这里故意将 BeanNameViewResolver 放到了 InternalResourceViewResolver 前面。

遍历顺序:

发现 InternalResourceViewResolver 会先被遍历。

结论:

在指定 order 属性的情况下,order 值越小的,越先会遍历。

<2>不设置 order 属性,遍历顺序是怎样的

在测试这个的时候,发现一个这样的现象:我将 BeanNameViewResolver 和 InternalResourceViewResolver 的 order 属性都去掉,我这里用的是 Jrebel 的热部署。发现再次请求的时候,

这两个视图的 order 属性值还和之前的一样:

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

为什么呢?想起了官方的描述:"在程序运行期间视图的状态不能更改,所以实现能被随意缓存",这里被缓存了。重启后来看真正的测试。

第一种情况:

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

第二种情况:将 bean 在 SpringMVC  Config 文件中的顺序进行替换,需要注意的是,重启服务器,否则它们的顺序还是会被缓存下来。重启后来看:

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

结论已经很明显了:

在同等优先级的情况下,遍历的顺序是由 ViewResolver 在 SpringMVC Config 文件中配置的顺序决定的,谁在前谁先遍历。

这里不对具体的每个视图解析器进行说明,路已经指明了。

3.ViewResolver 具体是怎么将 view name 解析为一个视图的?

先看 ViewResolver 中的 View resolveViewName(String viewName, Locale locale)

说明:

解析视图通过其名称。注意:允许 ViewResolver 链。

如果一个给定名称的view 没有在一个 ViewResolver 中定义,那么它应该返回 null。

然而它也不是必须的:有一些 ViewResolver 当尝试通过视图名称构建 View 对象失败后,不返回 null。而替代它的是,抛出一个异常。

以 org.springframework.web.servlet.view.AbstractCachingViewResolver 进行分析。

@Override
public View resolveViewName(String viewName, Locale locale) throws Exception {if (!isCache()) {
    return createView(viewName, locale);}
  else {Object cacheKey = getCacheKey(viewName, locale);View view = this.viewAccessCache.get(cacheKey);
    if (view == null) {
      synchronized (this.viewCreationCache) {view = this.viewCreationCache.get(cacheKey);
      if (view == null) {
        // Ask the subclass to create the View object.view = createView(viewName, locale);
        if (view == null && this.cacheUnresolved) {view = UNRESOLVED_VIEW;}
        if (view != null) {
          this.viewAccessCache.put(cacheKey, view);
          this.viewCreationCache.put(cacheKey, view);
          if (logger.isTraceEnabled()) {logger.trace("Cached view [" + cacheKey + "]");}}}}}
  return (view != UNRESOLVED_VIEW ? view : null);}
}

判断该视图是否被缓存,如果没有被缓存,则创建视图,如果被缓存,则从缓存中获取。

创建视图,以 InternalResourceViewResolver 和 BeanNameViewResolver 为例:

(1)InternalResourceViewResolver

org.springframework.web.servlet.view.UrlBasedViewResolver#createView

protected View createView(String viewName, Locale locale) throws Exception {// If this resolver is not supposed to handle the given view,// return null to pass on to the next resolver in the chain.if (!canHandle(viewName, locale)) {return null;}// Check for special "redirect:" prefix.if (viewName.startsWith(REDIRECT_URL_PREFIX)) {String redirectUrl = viewName.substring(REDIRECT_URL_PREFIX.length());RedirectView view = new RedirectView(redirectUrl, isRedirectContextRelative(), isRedirectHttp10Compatible());return applyLifecycleMethods(viewName, view);}// Check for special "forward:" prefix.if (viewName.startsWith(FORWARD_URL_PREFIX)) {String forwardUrl = viewName.substring(FORWARD_URL_PREFIX.length());return new InternalResourceView(forwardUrl);}// Else fall back to superclass implementation: calling loadView.
  return super.createView(viewName, locale);
}    

在创建视图前会检查返回值是否是以:"redirect:" 或 "forward:" 开头的。

如果是重定向:则创建一个重定向视图,返回创建的视图。如果是转发:则返回通过 转发 url 创建的 InternalResourceView 视图。

org.springframework.web.servlet.view.UrlBasedViewResolver#loadView

AbstractUrlBasedView view = buildView(viewName);
View result = applyLifecycleMethods(viewName, view);
return (view.checkResource(locale) ? result : null);

调用具体的 InternalResourceViewResolver ,然后又调用 父类的 buildView() 方法

org.springframework.web.servlet.view.UrlBasedViewResolver#buildView

protected AbstractUrlBasedView buildView(String viewName) throws Exception {AbstractUrlBasedView view = (AbstractUrlBasedView) BeanUtils.instantiateClass(getViewClass());view.setUrl(getPrefix() + viewName + getSuffix());String contentType = getContentType();
  if (contentType != null) {view.setContentType(contentType);}view.setRequestContextAttribute(getRequestContextAttribute());view.setAttributesMap(getAttributesMap());
  if (this.exposePathVariables != null) {view.setExposePathVariables(exposePathVariables);}
  return view;
}

可以看出:是通过 BeanUtils.instantiateClass(getViewClass()) 来创建 View 对象的。这个例子与其说是 InternalResourceViewResolver ,倒不如说是 UrlBasedViewResolver 类型的例子。

从这里也可以看出:该类型最终要到的目标URL为:getPrefix() + viewName + getSuffix()

(2)BeanNameViewResolver

public View resolveViewName(String viewName, Locale locale) throws BeansException {ApplicationContext context = getApplicationContext();if (!context.containsBean(viewName)) {// Allow for ViewResolver chaining.return null;}return context.getBean(viewName, View.class);
}    

org.springframework.context.support.AbstractApplicationContext#getBean(java.lang.String, java.lang.Class<T>)

public <T> T getBean(String name, Class<T> requiredType) throws BeansException {this.assertBeanFactoryActive();return this.getBeanFactory().getBean(name, requiredType);
}

可以看出:是通过 BeanFactory.getBean(String name, Class<T> requiredType) 来获取的。

三、视图渲染

1.View

官方文档:

* MVC View for a web interaction. Implementations are responsible for rendering* content, and exposing the model. A single view exposes multiple model attributes.** <p>This class and the MVC approach associated with it is discussed in Chapter 12 of* <a href="http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/">Expert One-On-One J2EE Design and Development</a>* by Rod Johnson (Wrox, 2002).** <p>View implementations may differ widely. An obvious implementation would be* JSP-based. Other implementations might be XSLT-based, or use an HTML generation library.* This interface is designed to avoid restricting the range of possible implementations.** <p>Views should be beans. They are likely to be instantiated as beans by a ViewResolver.* As this interface is stateless, view implementations should be thread-safe.

说明:

SpringMVC 对一个 web 来说是相互作用的(不太明白)。View 的实现类是负责呈现内容的,并且 exposes(暴露、揭露、揭发的意思,这里就按暴露解释吧,想不出合适的词语) 模型的。

一个单一的视图可以包含多个模型。

View 的实现可能有很大的不同。一个明显的实现是基于 JSP 的。其他的实现可能是基于 XSLT 的,或者是一个 HTML 生成库。

设计这个接口是为了避免约束可能实现的范围(这里是不是说,我们可以通过实现该接口来自定义扩展自定义视图?)。

所有的视图都应该是一个 Bean 类。他们可能被 ViewResolver 当做一个 bean 进行实例化。

由于这个接口是无状态的,View 的所有实现类应该是线程安全的。

2.View 的整个体系

3.具体渲染的一个过程

org.springframework.web.servlet.view.AbstractView#render

说明一下这个方法:

为指定的模型指定视图,如果有必要的话,合并它静态的属性和RequestContext中的属性,renderMergedOutputModel() 执行实际的渲染。

public void render(Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception {
  if (logger.isTraceEnabled()) {logger.trace("Rendering view with name '" + this.beanName + "' with model " + model +" and static attributes " + this.staticAttributes);}Map<String, Object> mergedModel = createMergedOutputModel(model, request, response);prepareResponse(request, response);renderMergedOutputModel(mergedModel, request, response);
}

这里只看 org.springframework.web.servlet.view.InternalResourceView#renderMergedOutputModel 这个方法

@Override
protected void renderMergedOutputModel(Map<String, Object> model, HttpServletRequest request, HttpServletResponse response) throws Exception {  // Determine which request handle to expose to the RequestDispatcher.HttpServletRequest requestToExpose = getRequestToExpose(request);  // Expose the model object as request attributes.
  exposeModelAsRequestAttributes(model, requestToExpose);// Expose helpers as request attributes, if any.
  exposeHelpers(requestToExpose);  // Determine the path for the request dispatcher.String dispatcherPath = prepareForRendering(requestToExpose, response);  // Obtain a RequestDispatcher for the target resource (typically a JSP).RequestDispatcher rd = getRequestDispatcher(requestToExpose, dispatcherPath);
  if (rd == null) {throw new ServletException("Could not get RequestDispatcher for [" + getUrl() +"]: Check that the corresponding file exists within your web application archive!");}  // If already included or response already committed, perform include, else forward.
  if (useInclude(requestToExpose, response)) {response.setContentType(getContentType());if (logger.isDebugEnabled()) {logger.debug("Including resource [" + getUrl() + "] in InternalResourceView '" + getBeanName() + "'");}rd.include(requestToExpose, response);}else {// Note: The forwarded resource is supposed to determine the content type itself.if (logger.isDebugEnabled()) {logger.debug("Forwarding to resource [" + getUrl() + "] in InternalResourceView '" + getBeanName() + "'");}rd.forward(requestToExpose, response);}
}

可以看到前面的几个步骤都是为 RequestDispatch 做准备,装填数据。最后,到目标页面是通过转发。

四、总结

介绍了 SpringMVC 视图解析和视图渲染问题是如何解决的。SpringMVC 为逻辑视图提供了多种视图解析策略,可以在配置文件中配置多个视图的解析策略。并制定其先后顺序。

这里所说的视图解析策略,就是指视图解析器。视图解析器会将逻辑视图名解析为一个具体的视图对象。再说视图渲染的过程,视图对模型进行了渲染,最终将模型的数据以某种形式呈现给用户。

到此为止,在我看来,SpringMVC 整个流程已经跑完,前面的几篇文章,从一个小栗子开始,然后分别介绍了请求映射问题,参数问题,返回值问题,到这篇文章,返回值处理问题

我认为这几个问题是整个 SpringMVC 的核心内容。其他的问题,都是建立在该问题的基础上,或者是对这几个问题的一种延伸。

还有想说的是,在边测试边看源码边写文章的时候,给我这么一个感觉,不论是何种开源框架,它所有的应用都是从源码中来的,不论哪个人或者那本书把这个知识讲的多好,

但是在我看来,想要学好某个框架,都要到它源码中去,找到它的根,这样才会有理有据,不会忘的那么快,纵然忘了,下次还是可以找出来为什么。

纵然在看源码的过程中,可能会遇到很多困难,比如英文单词不认识,整个句子读不通,但是如果你能结合自己的理解,

然后理解文档中的话,我相信对你帮助是很大的,其实这就是一种自学能力,摸的着,看得见。

算是给各位看客老爷的一种建议吧,愿各位在学习的道路上不要停滞不前。

转载于:https://www.cnblogs.com/solverpeng/p/5743609.html

SpringMVC核心——视图渲染(包含视图解析)问题相关推荐

  1. spring mvc DispatcherServlet详解之四---视图渲染过程

    整个spring mvc的架构如下图所示: 现在来讲解DispatcherServletDispatcherServlet的最后一步:视图渲染.视图渲染的过程是在获取到ModelAndView后的过程 ...

  2. spring(6) 渲染web视图

    [0]README 1)本文部分文字描述转自:"Spring In Action(中/英文版)",旨在review  "spring(6) 渲染web视图" 的 ...

  3. SpringMVC_视图解析(解析过程、视图、常见视图解析器、重定向)

    今天来说说SpringMVC视图是怎么解析的. 1.SpringMVC如何解析视图概述 1.1.无论控制器返回一个String,ModelAndView,View都会转换为ModelAndView对象 ...

  4. 系列四、SpringMVC响应数据和结果视图

    2019独角兽企业重金招聘Python工程师标准>>> 项目结构如下 一.返回值分类 一 返回字符串 Controller方法返回字符串可以指定逻辑视图的名称,根据视图解析器为物理视 ...

  5. 服务端第四次课程:MVC,控制器,视图渲染

    MVC,控制器,视图渲染 文章目录 MVC,控制器,视图渲染 1:什么是servlet 2:filter controller 3:spring MVC 的请求 1:作业 4:spittle 5:sp ...

  6. php渲染视图,Laravel 视图渲染:Blade 模板引擎

    Laravel 视图渲染:Blade 模板引擎 由 学院君 创建于3年前, 最后更新于 2年前 版本号 #1 53378 views 27 likes 0 collects Blade 简介 Blad ...

  7. 视图渲染、CPU和GPU卡顿原因及其优化方案

    视图渲染过程: 1.CPU 计算好显示内容提交到 GPU 2.GPU 渲染完成后将渲染结果放入帧缓冲区 3.视频控制器会按照 VSync 信号逐行读取帧缓冲区的数据,经过可能的数模转换传递给显示器显示 ...

  8. 《Spring In Action(第4版)》阅读总结(四)渲染Web视图

    渲染Web视图 将模型数据渲染为HTML 使用JSP视图 通过tiles定义视图布局 使用Thymealeaf视图 理解视图渲染 控制器只负责处理请求并返回模型数据和视图名 将控制器中请求处理逻辑与视 ...

  9. 操作虚拟dom模拟react视图渲染

    1.为什么要使用虚拟dom? 网页性能优化->尽量少操作DOM 2..虚拟DOM(Virtual DOM) VS js直接操作原生DOM(innerHTML) function Raw() {v ...

最新文章

  1. 1062 Talent and Virtue
  2. java.lang.ClassNotFoundException: org.codehaus.jackson.JsonProcessingException 异常解决方案
  3. PostgresSQL生成UUID
  4. Nmcli 网络管理命令行工具基础
  5. MPLS是怎么工作的?
  6. 据中心水冷系统备品备件管理新思路
  7. 【测试】ABAP发送HTML格式邮件FM
  8. javascript 对象方法、类方法、原型方法
  9. 揭秘各国总统们钟爱的手机
  10. Go协程通道锁故事化理解
  11. # 普通函数和箭头函数的区别
  12. play框架入门操作
  13. 揭密 GaussDB T 主备物理复制搭建过程(全)
  14. java传输对象_如何传输Java对象
  15. 自用Markdown颜色字体代码
  16. 微信再次重大更新,同时支持5个浮窗展示,你怎么看?
  17. 【方向盘】蚂蚁金服上市了,我不想努力了
  18. 从键盘输入一个数,判断是否为质数
  19. app inventor+tinywebDB远程控制掌控板
  20. foobar2000利用cue对ape进行分轨操作及其常见问题

热门文章

  1. 计算机软件需求规格说明规范_太阳能(光伏)组件安全规范测试简介_丙观科技
  2. 报错 ValueError: too many values to unpack (expected 2)
  3. go int 转char_GO语言实现 一 栈和队列
  4. ES6(二)——字符串模板、标签模板字符串、函数的默认参数、剩余参数、数组对象的展开语法、数值的表示、Symbol
  5. Vue项目中使用 路由导航守卫 处理页面的访问权限
  6. LeetCode 2156. 查找给定哈希值的子串(字符串哈希)
  7. HDFS Java API 实践
  8. java使用原生语句操作mongo_Java 中 MongoDB 使用指南
  9. Python中查找包含它的列表元素的索引,index报错!!!
  10. sql两个时间之间的小时差_2年级学生每天上学路上有两个小时车程,该如何利用好这个时间?-知乎亲子热点快报/2020/09/04...