Spring实战——Web中的Spring

第五章 构建Spring Web应用程序

1. Spring MVC起步

1.1 跟踪Spring MVC的请求

在请求离开浏览器时 ，会带有用户所请求内容的信息，至少会包含请求的URL。但是还可能带有其他的信息，例如用户提交的表单信息。请求旅程的第一站是Spring的DispatcherServlet。与大多数基于Java的Web框架一样，Spring MVC所有的请求都会通过一个前端控制器（front controller）Servlet。前端控制器是常用的Web应用程序模式，在这里一个单实例的Servlet将请求委托给应用程序的其他组件来执行实际的处理。在Spring MVC中，DispatcherServlet就是前端控制器。

DispatcherServlet的任务是将请求发送给Spring MVC控制器（controller）。控制器是一个用于处理请求的Spring组件。在典型的应用程序中可能会有多个控制器，DispatcherServlet需要知道应该将请求发送给哪个控制器。所以DispatcherServlet以会查询一个或多个处理器映射（handler mapping）来确定请求的下一站在哪里。处理器映射会根据请求所携带的URL信息来进行决策。一旦选择了合适的控制器，DispatcherServlet会将请求发送给选中的控制器 。

到了控制器，请求会卸下其负载（用户提交的信息）并耐心等待控制器处理这些信息。（实际上，设计良好的控制器本身只处理很少甚至不处理工作，而是将业务逻辑委托给一个或多个服务对象进行处理。） 控制器在完成逻辑处理后，通常会产生一些信息，这些信息需要返回给用户并在浏览器上显示。这些信息被称为模型（model）。不过仅仅给用户返回原始的信息是不够的——这些信息需要以用户友好的方式进行格式化，一般会是HTML。所以，信息需要发送给一个视图（view），通常会是JSP。

控制器所做的最后一件事就是将模型数据打包，并且标示出用于渲染输出的视图名。它接下来会将请求连同模型和视图名发送回DispatcherServlet 。这样，控制器就不会与特定的视图相耦合，传递给DispatcherServlet的视图名并不直接表示某个特定的JSP。实际上，它甚至并不能确定视图就是JSP。相反，它仅仅传递了一个逻辑名称，这个名字将会用来查找产生结果的真正视图。DispatcherServlet将会使用视图解析器（view resolver） 来将逻辑视图名匹配为一个特定的视图实现，它可能是也可能不是JSP。

既然DispatcherServlet已经知道由哪个视图渲染结果，那请求的任务基本上也就完成了。它的最后一站是视图的实现（可能是JSP） ，在这里它交付模型数据。请求的任务就完成了。视图将使用模型数据渲染输出，这个输出会通过响应对象传递给客户端。

1.2 搭建Spring MVC

在传统方式中，像DispatcherServlet这样的Servlet会配置在web.xml文件中，下面会使用Java将DispatcherServlet配置在Servlet容器中，而不会再使用web.xml文件。

（1）配置DispatcherServlet

（2）启用SpringMVC

1.3 Spittr应用简介

2. 编写基本的控制器

2.1 测试控制器

2.2 定义类级别的请求处理

2.3 传递模型数据到视图中

Model实际上就是一个Map（也就是key-value对的集合），它会传递给视图，这样数据就能渲染到客户端了。当调用addAttribute()方法并且不指定key的时候，那么key会根据值的对象类型推断确定。在本例中，因为它是一个List<Spittle>，因此，键将会推断为spittleList。

当视图是JSP的时候，模型数据会作为请求属性放到请求（request）之中，可以使用JSTL（JavaServer Pages Standard Tag Library）的<c:forEach>标签渲染spittle列表：

3. 接受请求的输入

Spring MVC允许以多种方式将客户端中的数据传送到控制器的处理器方法中，包括：

》查询参数（Query Parameter）。

》表单参数（Form Parameter）。

》路径变量（Path Variable）。

3.1 处理查询参数

为了实现这个分页的功能，我们所编写的处理器方法要接受如下的参数：

》before参数（表明结果中所有Spittle的ID均应该在这个值之前）。

》count参数（表明在结果中要包含的Spittle数量）。

3.2 通过路径参数接受输入

4. 处理表单

4.1 编写处理表单的控制器

为了防止重复提交（用户点击浏览器的刷新按钮有可能会发生这种情况），应该将浏览器重定向到新创建用户的基本信息页面。在处理POST类型的请求时，在请求处理完成后，最好进行一下重定向，这样浏览器的刷新就不会重复提交表单了。processRegistration()方法接受一个Spitter对象作为参数。这个对象有firstName、lastName、username和password属性，这些属性将会使用请求中同名的参数进行填充。

除了“redirect:”，InternalResourceViewResolver还能识别“forward:”前缀。当它发现视图格式中以“forward:”作为前缀时，请求将会前往（forward）指定的URL路径，而不再是重定向。

4.2 校验表单

Spitter参数添加了@Valid注解，这会告知Spring，需要确保这个对象满足校验限制。如果有校验出现错误的话，那么这些错误可以通过Errors对象进行访问，现在这个对象已作为processRegistration()方法的参数。（很重要一点需要注意，Errors参数要紧跟在带有@Valid注解的参数后面，@Valid注解所标注的就是要检验的参数。）通过调用Errors.hasErrors()来检查是否有错误。

5. 小结

第六章 渲染Web视图

1. 理解视图解析

2. 创建Jsp视图

Spring提供了两种支持JSP视图的方式：

》InternalResourceViewResolver会将视图名解析为JSP文件。另外，如果在你的JSP页面中使用了JSP标准标签库（JavaServer Pages Standard Tag Library，JSTL）的话，InternalResourceViewResolver能够将视图名解析为JstlView形式的JSP文件，从而将JSTL本地化和资源bundle变量暴露给JSTL的格式化（formatting）和信息（message）标签。

》Spring提供了两个JSP标签库，一个用于表单到模型的绑定，另一个提供了通用的工具类特性。

2.1 配置适用于Jsp的视图解析器

（1）配置InternalResourceViewResolver

（2）解析JSTL视图

让InternalResourceViewResolver将视图解析为JstlView，而不是InternalResourceView的话，那么我们只需设置它的viewClass属性即可。

2.2 使用Spring的Jsp库

（1）将表单绑定到模型上

Spring的表单绑定JSP标签库包含了14个标签，它们中的大多数都用来渲染HTML中的表单标签。但是，它们与原生HTML标签的区别在于它们会绑定模型中的一个对象，能够根据模型中对象的属性填充值。标签库中还包含了一个为用户展现错误的标签，它会将错误信息渲染到最终的HTML之中。

为了使用表单绑定库，需要在JSP页面中对其进行下图声明：

示例：<sf:form>会渲染会一个HTML <form>标签，但它也会通过commandName属性构建针对某个模型对象的上下文信息。在模型中必须要有一个key为spitter的对象，否则的话，表单不能正常渲染（会出现JSP错误）。这意味着我们需要修改一下SpitterController，以确保模型中存在以spitter为key的Spitter对象：

（2）展现错误

如果存在校验错误的话，请求中会包含错误的详细信息，这些信息是与模型数据放到一起的。我们所需要做的就是到模型中将这些数据抽取出来，并展现给用户。<sf:errors>能够让这项任务变得很简单。

在这里，它的path属性设置成了firstName，也就是指定了要显示Spitter模型对象中哪个属性的错误。如果firstName属性没有错误的话，那么<sf:errors>不会渲染任何内容。但如果有校验错误的话，那么它将会在一个HTML <span>标签中显示错误信息。例如，如果用户提交字母“J”作为名字的话，那么如下的HTML片段就是针对First Name输入域所显示的内容：

另外一种处理校验错误方式就是将所有的错误信息在同一个地方进行显示。为了做到这一点，我们可以移除每个输入域上的<sf:errors>元素，并将其放到表单的顶部，如下所示：

为了让这些错误信息更加易读。重新看一下Spitter类，我们可以在校验注解上设置message属性，使其引用对用户更为友好的信息，而这些信息可以定义在属性文件中：

（3）Spring通用的标签库

要使用Spring通用的标签库，我们必须要在页面上对其进行声明：

（4）展现国际化信息

对于渲染文本来说，是很好的方案，文本能够位于一个或多个属性文件中。借助<s:message>，我们可以将硬编码的欢迎信息替换为如下的形式：

Spring有多个信息源的类，它们都实现了MessageSource接口。在这些类中，更为常见和有用的是ResourceBundleMessageSource。它会从一个属性文件中加载信息，这个属性文件的名称是根据基础名称（base name）衍生而来的。ResourceBundleMessageSource就会试图在根路径的属性文件中解析信息，这些属性文件的名称是根据这个基础名称衍生得到的。 如下的@Bean方法配置了ResourceBundleMessageSource：

另外的可选方案是使用ReloadableResourceBundleMessageSource，它能够重新加载信息属性，而不必重新编译或重启应用。basename属性可以设置为在类路径下（以“classpath:”作为前缀）、文件系统中（以“file:”作为前缀）或Web应用的根路径下（没有前缀）查找属性。在这里，我将其配置为在服务器文件系统的“/etc/spittr”目录下的属性文件中查找信息，并且基础的文件名为“message”。配置如下：

（5）创建URL

<s:url>会接受一个相对于Servlet上下文的URL，并在渲染的时候，预先添加上Servlet上下文路径。例如，考虑如下<s:url>的基本用法：

另外，我们还可以使用<s:url>创建URL，并将其赋值给一个变量供模板在稍后使用：

默认情况下，URL是在页面作用域内创建的。但是通过设置scope属性，我们可以让<s:url>在应用作用域内、会话作用域内或请求作用域内创建URL：

在URL上添加参数的话，那么你可以使用<s:param>标签。

<s:url>标签还可以解决URL的转义需求。例如，如果你希望将渲染得到的URL内容展现在Web页面上（而不是作为超链接），那么你应该要求<s:url>进行HTML转义，这需要将htmlEscape属性设置为true。例如，如下的<s:url>将会渲染HTML转义后的URL：

如果你希望在JavaScript代码中使用URL的话，那么应该将javaScript-Escape属性设置为true：

（6）转义内容

<s:escapeBody>标签是一个通用的转义标签。它会渲染标签体中内嵌的内容，并且在必要的时候进行转义。

通过设置javaScriptEscape属性，<s:escapeBody>标签还支持JavaScript转义：

3. 使用Apache Titles视图定义布局

使用布局引擎，如Apache Tiles，定义适用于所有页面的通用页面布局。Spring MVC以视图解析器的形式为Apache Tiles提供了支持，这个视图解析器能够将逻辑视图名解析为Tile定义。

3.1 配置Titles视图解析器

在Spring中使用Tiles，需要配置几个bean。

》TilesConfigurer bean，它会负责定位和加载Tile定义并协调生成Tiles。

》TilesViewResolver bean将逻辑视图名称解析为Tile定义。

这两个组件又有两种形式：针对Apache Tiles 2和Apache Tiles 3分别都有这么两个组件。

definitions属性接受一个String类型的数组，也可以使用通配符加载“/WEB-INF/”目录下的所有名字为tiles.xml的文件。

配置TilesViewResolver

通过XML配置TilesConfigurer和TilesViewResolver：

定义Tiles，Apache Tiles提供了一个文档类型定义（document type definition，DTD），用来在XML文件中指定Tile的定义。每个定义中需要包含一个<definition>元素，这个元素会有一个或多个<put-attribute>元素。每个<definition>元素都定义了一个Tile，它最终引用的是一个JSP模板。在名为base的Tile中，模板引用的是“/WEB-INF/layout/page.jsp”。某个Tile可能还会引用其他的JSP模板，使这些JSP模板嵌入到主模板中。对于base Tile来讲，它引用的是一个头部JSP模板和一个底部JSP模板。

base Tile所引用的page.jsp模板如下面程序清单所示。

例如home Tile，它扩展了base。因为它扩展了base，因此它会继承base中的模板和所有的属性。尽管home Tile定义相对来说很简单，但是它实际上包含了如下的定义：

4. 使用Thymeleaf

JSP最明显的问题在于它看起来像HTML或XML，但它其实上并不是。JSP规范是与Servlet规范紧密耦合的。这意味着它只能用在基于Servlet的Web应用之中。JSP模板不能作为通用的模板（如格式化Email），也不能用于非Servlet的Web应用。

Thymeleaf模板是原生的，不依赖于标签库。它能在接受原始HTML的地方进行编辑和渲染。因为它没有与Servlet规范耦合，因此Thymeleaf模板能够进入JSP所无法涉足的领域。

4.1 配置Thymeleaf视图解析器

为了要在Spring中使用Thymeleaf，我们需要配置三个启用Thymeleaf与Spring集成的bean：

》ThymeleafViewResolver：将逻辑视图名称解析为Thymeleaf模板视图；

》SpringTemplateEngine：处理模板并渲染结果；

》TemplateResolver：加载Thymeleaf模板。

4.2 定义Thymeleaf模板

Thymeleaf在很大程度上就是HTML文件，与JSP不同，它没有什么特殊的标签或标签库。Thymeleaf之所以能够发挥作用，是因为它通过自定义的命名空间，为标准的HTML标签集合添加Thymeleaf属性。

（1）借助Thymeleaf实现表单绑定

<div>元素使用th:if属性来检查是否有校验错误。如果有的话，会渲染<div>，否则的话，它将不会渲染。在<div>中，会使用一个无顺序的列表来展现每项错误。<li>标签上的th:each属性将会通知Thymeleaf为每项错误都渲染一个<li>，在每次迭代中会将当前错误设置到一个名为err的变量中。

“${}”表达式（如${spitter}）是变量表达式（variable expression）。

“*{}”表达式，它们是选择表达式（selection expression）。

变量表达式是基于整个SpEL上下文计算的，而选择表达式是基于某一个选中对象计算的。在本例的表单中，选中对象就是<form>标签中th:object属性所设置的对象：模型中的Spitter对象。因此，“*{firstName}”表达式就会计算为Spitter对象的firstName属性。

5. 小结

第七章 Spring MVC的高级技术

本章内容：

》Spring MVC配置的替代方案

》处理文件上传

》在控制器中处理异常

》使用flash属性

1. SpringMVC配置的替代方案

1.1 自定义DispatcherServlet配置

在AbstractAnnotationConfigDispatcherServletInitializer将DispatcherServlet注册到Servlet容器中之后，就会调用customizeRegistration()，并将Servlet注册后得到的Registration.Dynamic传递进来。通过重载customizeRegistration()方法，我们可以对DispatcherServlet进行额外的配置。

借助customizeRegistration()方法中的ServletRegistration.Dynamic，我们能够完成多项任务，包括通过调用setLoadOnStartup()设置load-on-startup优先级，通过setInitParameter()设置初始化参数，通过调用setMultipartConfig()配置Servlet 3.0对multipart的支持。在前面的样例中，我们设置了对multipart的支持，将上传文件的临时存储目录设置在“/tmp/spittr/uploads”中。

1.2 添加其他的Servlet和Filter

基于Java的初始化器（initializer）的一个好处就在于我们可以定义任意数量的初始化器类。因此，如果我们想往Web容器中注册其他组件的话，只需创建一个新的初始化器就可以了。最简单的方式就是实现Spring的WebApplicationInitializer接口。

1.3 在web.xml中声明DispatcherServlet

2. 处理multipart形式的数据

multipart格式的数据会将一个表单拆分为多个部分（part），每个部分对应一个输入域。在一般的表单输入域中，它所对应的部分中会放置文本型数据，但是如果上传文件的话，它所对应的部分可以是二进制。在编写控制器方法处理文件上传之前，我们必须要配置一个multipart解析器，通过它来告诉DispatcherServlet该如何读取multipart请求。

2.1 配置multipart解析器

DispatcherServlet并没有实现任何解析multipart请求数据的功能。它将该任务委托给了Spring中MultipartResolver策略接口的实现，通过这个实现类来解析multipart请求中的内容。

从Spring 3.1开始，Spring内置了两个MultipartResolver的实现供我们选择：

》CommonsMultipartResolver：使用Jakarta Commons FileUpload解析multipart请求；

》StandardServletMultipartResolver：依赖于Servlet 3.0对multipart请求的支持（始于Spring 3.1）。

在这两者之间，StandardServletMultipartResolver可能会是优选的方案。它使用Servlet所提供的功能支持，并不需要依赖任何其他的项目。如果我们需要将应用部署到Servlet 3.0之前的容器中，或者还没有使用Spring 3.1或更高版本，那么可能就需要CommonsMultipartResolver了。

》上传文件的最大容量（以字节为单位）。默认是没有限制的。

》整个multipart请求的最大容量（以字节为单位），不会关心有多少个part以及每个part的大小。默认是没有限制的。

》在上传的过程中，如果文件大小达到了一个指定最大容量（以字节为单位），将会写入到临时文件路径中。默认值为0，也就是所有上传的文件都会写入到磁盘上。

假设我们想限制文件的大小不超过2MB，整个请求不超过4MB，而且所有的文件都要写到磁盘中。下面的代码使用MultipartConfigElement设置了这些临界值：

2.2 处理multipart请求

<form>标签现在将enctype属性设置为multipart/form-data，这会告诉浏览器以multipart数据的形式提交表单，而不是以表单数据的形式进行提交。在multipart中，每个输入域都会对应一个part。除了注册表单中已有的输入域，我们还添加了一个新的<input>域，其type为file。这能够让用户选择要上传的图片文件。accept属性用来将文件类型限制为JPEG、PNG以及GIF图片。根据其name属性，图片数据将会发送到multipart请求中的profilePicture part之中。

以Part的形式接收上传的文件，Spring MVC也能接受javax.servlet.http.Part作为控制器方法的参数。如果使用Part来替换MultipartFile的话，那么processRegistration()的方法签名将会变成如下的形式：

Part接口与MultipartFile并没有太大的差别（哈哈哈），值得一提的是，如果在编写控制器方法的时候，通过Part参数的形式接受文件上传，那么就没有必要配置MultipartResolver了。只有使用MultipartFile的时候，我们才需要MultipartResolver。

3. 处理异常

3.1 将异常映射为HTTP状态码

3.2 编写异常处理的方法

4. 为控制器添加通知

5. 跨重定向请求传递数据

5.1 通过URL模板进行重定向

5.2 使用flash属性

6. 小结

第八章 使用Spring Web Flow

 

第九章 保护Web应用