1、AbstractWizardFormController
AbstractWizardFormController能够实现向导式的页面。如果用户需要填写的表单内容很多,就有必要将其拆为几个页面,使用户能通过“上一步”和“下一步”按钮方便地在向导页面间导航,例如,设计一个在线调查的向导,就可以方便地引导用户一步一步完成调查表单的填写。
我们以注册新用户为例,RegisterController需要用户填写基本资料、联系方式和详细地址,由于表单内容较多,我们让用户分3个页面分步完成注册。
我们无须处理“下一步”和“上一步”按钮,Spring会自动显示正确的页面,我们只需要处理最后用户单击“完成”按钮提交的整个表单对象。
那么,Spring是如何知道下一个或上一个需要显示的页面呢?
除了指定command Class为User对象外,我们还需要将几个View的逻辑名称注入到RegisterController的pages属性中,注意到 AbstractWizardController的pages是从下标0开始计数的,因此,我们将注册的3个页面依次命名为 registerStep0.jsp、registerStep1.jsp和registerStep2.jsp。
除了指定pages属性外,我们还需要按照一定的规则来编写JSP页面,才能告诉Spring如何显示下一页或上一页。在表单的提交按钮上,必须以_target+索引命名按钮,例如:
当用户单击“完成”按钮后,Spring将调用processFinish()方法处理表单。
如果需要验证表单,在AbstractWizardController中,就无法使用Validator来进行验证,因为用户在每个页面仅填写了部分内容,直到用户单击“完成”按钮时,整个表单对象才被填充完毕,因此,在任何一个页面中验证Command都将失败,为此,验证必须在 AbstractWizardController的validatePage()方法中进行,Spring将传入page参数,我们就根据这个参数对 command对象进行部分验证。
若验证未通过,则将停留在当前页,并可以通过<form:errors>显示相应的错误信息,待用户更正后,才可以继续前进到下一页。
也许注意到了,第一个页面有两个口令框,其中,第二个口令框名称为password2,在User对象中并没有对应的属性,Spring不会自动绑定它。那么,如何验证用户两次输入的口令是否一致呢?我们一般不愿意更改User对象,因为User对象很可能对应数据库中的某个表,而数据库表不会存储同一用户的两份相同的口令。此时,可以通过 JavaScript来验证,既方便,又能避免修改User对象。因此,在Web应用程序的设计中,不要仅仅拘泥于JavaEE框架,对于 JavaScript、AJAX等技术也要充分利用。
2、重定向URL
重定向URL会使服务器向客户端发送一个 Redirect响应,并包含一个目标URL。客户端接收到Redirect响应后,会立刻重新请求新的URL,这一点和Forward不同。前者使客户端发送了两次独立的HTTP请求,而后者请求是在服务器内部处理的,客户端并不知道服务器端对Request是否做了Forward处理。
重定向功能的主要用途是为了在服务器端修改了某一资源的URL后,原有客户仍可以继续通过原来的URL访问该资源。由于重定向会使客户端发送两次请求,所以降低了网络效率,并且不便于用户在浏览器中单击“后退”按钮返回上一个页面。对于Web应用程序而言,决不能大量使用重定向功能。
在Controller中实现 Redirect也非常容易。最简单的方法是直接调用HttpServlet Response对象的sendRedirect()方法,然后返回null。一旦返回的ModelAndView为null,Spring就认为 Controller自己已经完成了请求处理,不再按照常规的MVC流程继续处理请求。
例如,对于用户注销登录的操作,在清理了Session的内容后,就可以将用户重定向到登录页面。LogoutController代码如下。
另一种实现重定向的方法不用直接调用HttpServletResponse对象的sendRedirect()方法,而是返回一个带有 “redirect:”前缀的View,这样,ViewResolver就知道这是一个重定向操作,于是不再渲染视图,而是直接向客户端发送 Redirect响应。
return new ModelAndView("redirect:login.do");
Spring还提供了一个RedirectView对象,也可以实现重定向操作,不过使用RedirectView使Controller和View的耦合稍微紧密了一点,推荐的方法是使用“redirect:”前缀。
使用重定向要注意的一点是,重定向的资源不可位于/WEB-INF/目录下,因为用户无法通过URL直接访问位于/WEB-INF/目录下的资源,而使用MVC流程通过forward调用/WEB-INF/目录下的资源是允许的。
3、处理异常
如果Controller在处理用户请求时发生了异常,自己捕获异常并跳转到出错页面会使核心逻辑混乱。Spring的MVC框架提供了一个HandlerExceptionResolver,为所有的Controller抛出的异常提供一个统一的入口。
MyHandlerExceptionResolver 根据Exception类型判断如何处理异常,如果是NeedLoginException,说明系统要求用户登录,这时直接将用户导向到登录页面;对于其他类型的异常,则直接将异常的错误信息显示给用户,注意返回的视图名称为“error”,实际的视图文件即为“/error.jsp”。
使用 HandlerExceptionResolver可以避免在应用程序的每一个Controller中都去处理异常,将异常统一放到 HandlerExceptionResolver中可以极大地简化异常处理逻辑,也便于在一个统一的地方记录异常日志。对于无法处理的异常,可以给用户显示一个友好的出错页面。
4、拦截请求
我们已使用 Filter可以拦截用户请求,并实现相应的处理。Spring的MVC框架也提供了一个拦截器链,可以由多个HandlerInterceptor构成,允许在Controller处理用户请求的前后有机会处理请求。和Filter相比,HandlerInterceptor是在Spring的IoC 容器中配置的,可以注入任意的组件,而Filter定义在Spring容器之外,因此,注入IoC组件比较困难,或者难以得到一个优雅的设计。
(1)preHandle()方法在Controller执行前调用,其返回值指定了是否应当继续处理请求。若返回false,Spring MVC框架将不再继续调用下一个拦截器,也不会将请求交给Controller处理,整个请求处理将到此结束。
(2)postHandler()方法在Controller执行完毕后调用,此时Controller仅返回了ModelAndView对象,还没有对视图进行渲染,在这个方法中有机会对ModelAndView进行修改。
(3)afterCompletion()方法在整个请求全部完成后调用,通过判断参数ex是否为null就可以判断是否产生了异常。
通过HandlerInterceptor,就有机会在一个请求执行的3个阶段对其进行拦截。例如,为了统计Web应用程序的性能,我们设计了一个性能拦截器,将每个用户请求的处理时间记录下来。PerformanceHandlerInterceptor实现如下。
由于我们必须保证PerformanceHandlerInterceptor是线程安全的,因此,绝不可将起始时间记录在PerformanceHandlerInterceptord 的成员变量中。由于每个请求都对应一个独立的HttpServletRequest实例,因此,将起始时间放入HttpServletRequest实例中就保证了线程安全。
然后,将其添加到handlerMapping中的interceptor列表中。
运行应用程序,在浏览器中请求/login.do,查看控制台输出如下。
[2006/11/20 22:33:41.857] URL: /login.do
[2006/11/20 22:33:41.857] Execute: 3781ms.
[2006/11/20 22:33:45.325] URL: /login.do
[2006/11/20 22:33:45.325] Execute: 0ms.
可以看到PerformanceHandlerInterceptor记录的处理时间。首次执行/login.do请求时,耗时3秒多,这是因为服务器需要编译JSP文件,随后刷新页面,由于可以跳过JSP的编译步骤,/login.do请求在1ms内就完成了。
文件上传是Web应用程序中常见的功能。本质上,浏览器在向服务器发送文件时,其HTTP请求必须以multipart/form-data的形式发送,该规范定义在RFC 2388(http://www.ietf.org/rfc/rfc2388.txt)中,可以实现一次上传一个或多个文件。不过,JavaEE的Web 规范并没有内置处理multipart请求的功能,因此,要实现文件上传,就必须借助于第三方组件,或者自己手动编码解析 HttpServletRequest。
Apache Commons FileUpload(http://jakarta.apache.org/commons/fileupload)组件和COS FileUpload(http://www.servlets.com/cos)组件都是常见的处理文件上传的组件,Spring很好地对这两种组件进行了封装。在Spring中处理文件上传时,根本无须与这两个组件的API打交道,只需用到Spring提供的 MultipartHttpServletRequest对象,就可以轻松实现文件上传的功能。
默认地,Spring不会处理文件上传,即所有的以multipart/form-data形式发送的请求都不被处理,如果要处理Multipart请求,需要在Spring的XML配置文件中申明一个MultipartResolver。
maxUploadSize属性指定了最大所能上传的文件大小,若超出了最大范围,Spring将会直接抛出异常。
如果一个请求不是Multipart请求,它就会按照正常的流程处理;
如果一个请求是Multipart请求,Spring就会自动调用MultipartResolver,然后将 HttpServletRequest请求变为MultipartHttpServletRequest请求,开发者只需要处理 MultipartHttpServletRequest对象就可以了。
如何得知一个请求是否是MultipartHttpServletRequest类型呢?通过instanceof操作就能非常简单地判断出来。我们在UploadController中实现文件上传的代码如下。
仔细查看上面的代码,可能会发现,我们根本没有调用Commons FileUpload或COS FileUpload组件的API,Spring已经完全为我们封装好了。那么,Spring如何确定使用Commons FileUpload还是使用COS FileUpload呢?答案是发现哪个就用哪个。
如果在/WEB-INF/lib目录下放置Commons FileUpload的jar包,Spring就会自动使用Commons FileUpload,COS FileUpload也是如此,这样带来的好处是完全屏蔽了底层组件的API,如果需要替换底层组件,只需要替换相应的jar包,甚至连XML配置文件都不用改动。
在 WebUpload工程中,我们使用的是Commons FileUpload,只需将commons- fileupload.jar和commons-io.jar放到/WEB-INF/lib目录下,剩下的事情就由Spring处理了。使用任何文本编辑器编写一个最简单的上传文件的index.html页面。
配置好DispatcherServlet后,运行这个Web应用程序,打开index.html,选择待上传的文件。文件上传成功后,就可以在服务器的Web应用的根目录下找到已上传的文件。
对于非file类型的表单字段,仍可以调用MultipartHttpServletRequest的getParameter()方法获得相应的字段值,因为MultipartHttpServletRequest也实现了HttpServletRequest接口。
也可以在SimpleFormController中将表单中上传的文件绑定到byte[]类型的属性中,不过,如果上传文件较大,则将消耗较大的服务器内存,因此,采用何种解决方案需要视情况而定。
联系客服