目录
Spring不仅支持传统(基于Servlet)的Web开发,也支持JSR-168 Portlet开发。 Portlet MVC框架尽可能多地采用Web MVC框架,使用相同的底层表现层抽象和整合技术。所以, 在继续阅读本章前,务必温习第 13 章 Web MVC framework Web框架和第 14 章 集成视图技术两章。
请牢记,在Spring MVC中的概念和Spring Porlet MVC中的相同的同时,JSR-168 Portlet 独特的工作流程造成了一些显著的差异。
Porlet工作流程和Servlet的主要差异在于,Portlet的请求处理有两个独特 的阶段:动作阶段和显示阶段。动作阶段会有“后台”数据改变或动作的代码,这些代码 只会执行一次。显示阶段会产生用户每次刷新时的看到的显示内容。重要的是, 在单个请求的整个处理过程中,动作阶段只会被执行一次,而显示阶段可能会被执行多次。 这就提供了(并且要求)在改变系统持久状态的活动和产生显示内容的活动之间 有一个清晰的分层。
这种两阶段的请求处理是JSR-168规范的一个优点,比如,可以自动地更新动态
的搜索结果,不需要用户特意去再次执行搜索。许多其它的Portlet MVC框架试图向开
发人员彻底隐藏这种两阶段处理,让框架看上去尽可能和传统的Servlet开发相同 - 在我们
看来,这种方式去掉了使用Portlet的一个主要好处,所以在Spring Portlet MVC
框架里分离的两阶段处理被保留了下来,这主要表现在,Servlet版本的MVC类将只
有一个方法来处理请求,而Portlet版本的MVC类里将会有两个方法:一个用在动作
阶段,另一个用在显示阶段。比如,在Servlet版本的 AbstractController
有
handleRequestInternal(..)
方法,Portlet版本的
AbstractController
有
handleActionRequestInternal(..)
和
handleRenderRequestInternal(..)
方法。
这个框架是围绕着分发器DispatcherPortlet
设计的,分发器把请求转发给处理
器。和Web框架的DispatcherServlet
一样,
这个框架还有可配置的处理器映射和视图解析,同时也支持文件上传。
Portlet MVC不支持本地化解析和主题解析 - 它们是portal/portlet容器
的范畴,并不适合放在Spring框架里。但是,Spring里所有依赖本地化(比如消息的
国际化)仍旧可以工作,因为DispatcherPortlet
在以
DispatcherServlet
相同的方式暴露当前的本地化信息。
缺省的处理器是一个非常简单的
Controller
接口,它提供了两个方法:
void handleActionRequest(request,response)
ModelAndView handleRenderRequest(request,response)
这个框架包含了许多相同的控制器实现层次,比如,
AbstractController
,
SimpleFormController
等。它在数据绑定、命令对象使用、
模型处理和视图解析等方面和Servlet框架相同。
这个框架利用了一个特殊的桥Servlet
ViewRendererServlet
来使用Servlet框架里的视图显示
功能,这样,Portlet请求就被转化为Servlet请求,Portlet视图能够以通常的
Servlet底层代码来显示。这意味着,在Portlet里仍能使用当前所有的显示方法,
如JSP、Velocity等。
Spring Portlet MVC支持Web Bean,这些Bean的生命周期在于当前的HTTP请求
或HTTP Session
(一般的和全局的)里,这不是
框架自身的特性,而是由使用的容器的
WebApplicationContext
提供的。
第 3.4.4 节 “其他作用域”详细地描述了这些Bean的作用范围。
Spring发布包带有完整的Spring Portlet MVC示例,这个应用演示了所有Spring Portlet MVC框架的功能和特色。
你可以在samples/petportal
目录下找到这个'petportal'应用。