BlogJava-☆蓝色梦想☆-随笔分类-JSF

JavaServer Faces in Action

☆蓝色梦想☆ — Sat, 10 Dec 2005 03:09:00 GMT

http://realzar.5u6.net

☆蓝色梦想☆ 2005-12-10 11:09 发表评论

选择JSF不选Struts

☆蓝色梦想☆ — Thu, 08 Dec 2005 01:44:00 GMT

一个客户不知道该选用Struts还是JSF。就像你预料的那样，我通常会问：这2中框架之间有什么区别？当然，除了我的这个客户外很多人都面临这样的选择。

总的来说，我建议在新项目中优先考虑JSF。虽然常常有一些商业上的因素迫使我们为现有的项目选择了Struts，而且那些解决方案还有待考验，但是，让我们面对一个事实：JSF比Struts好多了。

下面是我选择JSF而不选Struts的十大理由：

1.Components(组件)
2.Render Kits
3.Renderers
4.Value Binding Expressions（值绑定表达式）
5.Event Model（事件模型）
6.Extensibility(可扩展性)
7.Managed Beans(Dependency Injection 依赖注入)
8.POJO Action Methods
9.JSF is the standard Java-based web app framework (JSF是java web应用程序的标准框架)
10.There's only one Struts(只有一个Struts)

10.There's only one Struts(只有一个Struts) Struts 是一个开源产品，然而JSF是一个标准。这个细节常常被新的JSF学习者忽略，其实这是显而易见的，因为我们有多个JSF的实现。虽然JSF还很不成熟，但是我们已经有了2个优秀的JSF实现可以选择：Sun的参考实现和Apache的MyFaces。另一方面，我们只有一个Struts。

9.JSF is the standard(JSF是标准) JEE 5.0要提供一个JSF的实现，这表明JSF不久将会无处不在。这可能与你无关，但是和工具供应商密切相关。现在大概有50个java web应用程序框架，工具供应商不会情愿去支持一个特别的框架，但是他们会毫不犹豫的去支持一个标准。而且不止供应商，开源项目也会迅速的聚集在JSF的四周，争先恐后的去实现相同的功能。比如说，直到我们去实现本质上和Shale的Tapestry差不多的视图的时候，我才知道Facalets。（从长远来看，我相信这种冗余是件好事，会给我们带来好处）

8.POJO Action Methods Struts的行为是和 Struts的API绑定在一起的，但是JSF的行为方法可以在POJPO中实现。这意味着你不用在表单和模型对象之间实现一个多余的行为层。顺便说一下，在JSF里面没有行为对象，行为在模型对象中实现。但是也请注意一点：如果你愿意你也可以生成与JSF独立的行为对象。在Struts里面，你有 Form Bean和Action Bean。Form Bean包含数据而Action Bean包含逻辑。OO狂会想去合并前2者，在Struts你办不到。但是在JSF中，你可以分开数据和逻辑，也可以合并到一个对象中，一切由你决定。

7.Managed Beans(Dependency Injection 依赖注入) 和Spring一样，JSF也使用了依赖注入（DJ）（或控制反转（IoC））去实例化和初始化Bean。Struts的确为你生成了Form Bean和Action Bean，但是JSF可以为你生成各种各样的Managed Bean。

6.Extensibility(可扩展性) 这个很重要。JSF有6个对象实现了这个框架的大部分功能，而且你可以很容易的用你自己的实现代替原有实现。比如你想加一个自定义参数在JSF表达式语言里面，或是添加一个自己的视图控制器以便于区分组件和HTML。事实上Shale实现了上面的功能。如果你还没有满足，JSF提供了几个地方你可以轻松的控制JSF的生命周期。Shale给你的会更多。

5.Event Model（事件模型） JSF的事件模型使你可以对值改变，动作，JSF生命周期阶段变换等作出反应。在JSF1.1中，那些事件都是在服务器端处理的，这肯定是一个缺陷，好在JSF2.0计划支持客户端事件，拭目以待吧。

4.Value Binding Expressions（值绑定表达式）在Struts 中，你负责把数据从Form传递到模型对象。你实现的Action的execute方法是把Form作为一个参数。然后你再手动的把数据从Form Bean里面取出放到模型对象里面。你要为应用里面的每个Form做这些事情，然而在JSF里面，你只需像这样：#{model.property} 就够了，其他的交给JSF来处理。

3.Renderers 你有看过Struts的标签的源代码吗？它直接生成HTML。JSF组件标签什么都不生成，它和服务器上的一对component-renderer对应。Component维护组件状态，rendered负责获得视图。重点是renderers是可插拔的，即你可以根据自己需求实现然后替代掉默认实现。比如说我在NFJS上面的Felix谈话中举例说明了怎么去实现一个自定义的label renderer。你只需要配置你的renderer，JSF就会自动在你的应用程序里面使用他。

2.Render Kits 在几年前我曾经有份Struts咨询工作，我们必须同时支持浏览器和无线设备，非常痛苦。但是用JSF来完成那个任务非常容易，因为你可以生成你自己的render kit－为一种特定显示技术的renderers的集合－然后配置到JSF里面。

1.Components(组件) 组件是Struts和JSF之间最大的区别。就像Swing一样，JSF提供丰富的底层构件去开发组件然后添加到标准的组件集。那些底层构件让你很容易的生成自己的组件并且和别人共享。现在我们到处都能看到自定义组件跳出来，比如说Oracle的ADF和MyFaces，两者都提供了丰富的组件集，就像 javascript日历，tree等等。当然，组件只是一部分。典型的是，组件都和一个独立的renderer对应，这给我们带来了真正的好处（看第3 条）。但是和JSF中的很多东西一样，你不一定要墨守成规。只要你愿意，你可以实现render自己的组件，虽然这样你会失去给组件加入别的 renderer的能力。

☆蓝色梦想☆ 2005-12-08 09:44 发表评论

集成 Struts、Tiles 和 JavaServer Faces

☆蓝色梦想☆ — Thu, 08 Dec 2005 01:26:00 GMT

您是否想将 JavaServer Faces (JSF)的强大前端功能、Tiles 的内容格式编排优势和 Struts controller 层的灵活性都加入到您的J2EE Web 应用程序中？企业级 Java 专家 Srikanth Shenoy 和 Nithin Mallya 为您展示了如何将这三者的功能集成到一起。本文演示了如何在 Struts-Faces集成库中定制类以使得它们可以与 Tiles 和 JSF 一同使用，并用一个实际的例子解释了这个过程背后的基本原理以及如何使用新的一组类的细节。

将 Struts、Tiles 和 JavaServer Faces (JSF) 一起使用，开发人员可以实现易于管理和重用的、健壮的、界面清晰的 Web 应用程序。

Struts 框架推出已经有一段时间了，它已经成为在开发 J2EE Web 应用程序时开发人员所采用的事实上的标准。Tiles 框架是在 Struts 之后不久出现的，它通过为开发人员提供用组件组装展示页面的能力开拓了自己的生存环境。JSF 是 Web 应用程序框架中最新的成员，它提供了验证用户输入和处理用户事件的机制，最重要的是，这是一种以协议无关的方式呈现用户界面组件的方法(有关这些技术的概况，参见本文相关页面“ The major players”)。

尽管 Struts 和 JSF 中有一些功能是重叠的，但是它们在其他方面起到了互为补充的作用。这三种技术的结合可以为开发 Web 应用程序、组织其展示和以协议无关的方式呈现定制的用户界面(UI)组件提供一种高效的途径。

为了运行本文中的示例代码，需要 Struts 1.1、Tiles、JavaServer Faces Reference Implementation (JSF-RI) Early Access Release 4.0 以及 Struts-Faces 0.4。Jakarta 项目提供的 Struts 1.1 发行版本将 Struts 和 Tiles 捆绑发布。还可以从 Jakarta 项目上下载 Struts-Faces 集成库。JSF-RI 是 Sun 的 Web 开发工具包(Web Services Developer Pack)的一部分(在参考资料中有这些下载和示例代码的链接)。

现在回到集成三种技术的细节上。首先有个坏消息：在本文发表的时候，这三种技术是不能直接互操作的。好消息是：在本文中，我们展示了集成 Struts、Tiles 和 JSF 的方法。我们假设您已经了解 Struts 和 Tiles。对 JSF 有一些了解会有帮助(参阅参考资料中提供的 developerWorks 上的 JSF 教程的链接)，但是不了解也不妨碍对本文的理解。

JSF 简介

JSF 应用程序是使用 JSF 框架的普通 J2EE Web 应用程序，JSF 框架提供了丰富的 GUI 组件模型，这些模型体现了真正的 GUI 框架内涵。您可能听人们说过，尽管某种技术不错，但是它的外观仍然需要改进。是的，用 HTML 组件构建平淡无奇的页面的日子已经过去了，如果使用 JSF 的话，具有更高级 GUI 外观的日子就在眼前。您会问，怎么做呢？树形组件、菜单组件和图形是已经存在的 UI 组件，这些 JSF 一定要提供。更进一步，JSF 通过提供容易使用的 API 鼓励创建自定义组件。

注: 这里所提到的 UI 组件是 Sun 提供的示例的一部分。像所有规范一样，实际的实现由不同的提供商完成。

在传统的使用模型-视图-控制器(MVC)的 Web 应用程序中，GUI 组件是由处理展示和业务逻辑的自定义标记所表示的。这样就出现了必须“编写与客户机设备打交道的代码”的问题，这会产生重复的代码。使用 JSF 就不会有这个问题。

JSF 结构将 展示逻辑 (“什么”)与 UI 组件的 业务逻辑 (“为什么”和“如何”)分离。通过在 JSP 页面中使用 JSF 标记，就可以将 renderer 与 UI 组件关联在一起。一个 UI 组件可以用不同的 renderer 从而以不同的方式呈现。特定于 UI 组件的代码在服务器上运行，并且响应用户操作所产生的事件。

JSF-RI 提供了一个 render kit，它带有一个自定义标记库，用以从 UI 组件呈现 HTML。它还提供了根据需要定制这些组件外观的能力。如果需要特殊的组件，那么可以为特定的客户机设备构造定制的标记并让它与一个子 UI 组件和定制的 renderer 相关联。对于不同的设备，您所需要做的就是指定不同的 renderer。

JSF 和 UI 组件

您可能已经用 Java AWT 或者 Swing API 创建过 Java GUI 应用程序，所以您应该熟悉 JSF 的 UIComponent (它与 AWT 或者 Swing 组件很相像)。它储存其子组件的树(如果有的话)并为客户端发生的动作生成标准事件，例如单击一个按钮以提交表单。这些事件缓存在 FacesContext 中。您可以用自定义标记关联每一个这种事件的处理程序。例如，用一个自定义的 ActionListener 处理用户单击或者表单提交。

JSF UIComponent 、 Renderer 和标记总是共同工作的。所有 JSP 自定义标记都是通过继承 UIComponentTag 创建的。 doStart 和 doEnd 方法总是在 UIComponentTag 类中实现。您只需在这些标记类中提供其他的功能。

图 1展示了自定义标记、UI 组件和 renderer 之间的关系。客户机浏览器访问用 JSF 标记( jsf:myTag )表示 UI 组件( MyComponent )的 JSP 页面。这个 UI 组件运行在服务器上，并用适当的 renderer ( MyRenderer )以 HTML 的形式呈现给客户。这个 JSP 页面表现了在 JSF-RI 中使用带自定义标记的用户界面组件而不是在 HTML 中对它们进行编码。

例如，图 1 展示了 h:panel:group 标记的使用。这个标记用于将一个父组件下面的各个组件组织到一起。如果与像 panel_grid 和 panel_data 这样的其他面板标记共同使用，那么它会在运行时生成 HTML 表中的列的标记。JSF-RI-提供的 html_basic 标记库用于表示像文本字段、按钮这样的 HTML 组件。

图1. 呈现一个 JSF 页面

JSF 生命周期

JSF 生命周期包括六个阶段：一个传入的请求可能会经历全部阶段，也可能不经历任何阶段，这取决于请求的类型、在生命周期中发生的验证和转换错误以及响应的类型。JSF 框架处理由 JSP 页生成的 Faces 请求，并返回 faces或者 non-faces 响应。

在提交一个 JSF 表单，或者当用户单击指向在 URL 中具有 /faces 前缀的 URL 的链接时，就会出现 faces 响应。所有 faces 请求都由一个 FacesServlet 处理 -- 这是 JSF 中的控制器。

发送给一个 servlet 或者一个没有 JSF 组件的 JSP 页面的请求称为 non-faces 请求。如果结果页中有 JSF 标记，那么它就称为 faces 响应，如果没有 JSF 标记，就是 non-faces 响应。

JSF 生命周期有六个阶段：

重建请求树
应用请求值
进行验证
更新模型值
调用应用程序
呈现响应

根据 JSF 规范，每一阶段表示请求处理生命周期的一个逻辑概念。不过在 JSF-RI 中，这些阶段是由具有对应名字的实际类表示的。下面一节描述了每一阶段是如何对请求进行处理并生成响应的。您将首先看到的是处理一个 faces 请求所涉及的阶段，然后是处理 faces 响应所涉及的阶段。

处理 faces 请求

为了理解 JSF 请求处理，请看 FlightSearch.jsp，这是清单 1中的一个简单的 JSF 表单。一个 JSF 页面基本上就是这个样子的。这个 JSF 表单有输入文本字段 from和 to cities、 departure 和 return dates，还有提交和重设表单的按钮(我们会在稍后分析清单1中每一个标记的意义)。现在，假设提交这个表单产生了一个 faces 请求。

这个请求被 FacesServlet 所接收、并在向客户发回响应之前通过不同的阶段。图 2展示了如何对 JSF 请求进行处理。让我们看一看这是如何进行的。

1. 接收请求
FacesServlet 接收请求并从 FacesContextFactory 得到 FacesContext 的一个实例。

2. 委托生命周期处理
FacesServlet 通过对在 faces 上下文中传递的 Lifecycle 实现调用 execute 方法将生命周期处理委托给 Lifecycle 接口。

3. Lifecycle 执行每一阶段
Lifecycle 实现执行从重建组件树阶段开始的每一阶段。

4. 创建的组件树
在重建组件树阶段，用 travelForm 中的组件创建一个组件树。这个树以 UIForm 作为根，用不同的文本字段和按钮作为其子组件。

fromCity 字段有一个验证规则，它规定其不能为空，如 validate_required 标记所示。这个标记将 fromCity 文本字段与一个 JSF Validator 链接起来。

JSF 有几个内建的验证器。相应的 Validator 是在这个阶段初始化的。这个组件树缓存在 FacesContext 中、并且这个上下文会在后面用于访问树及调用任何一个事件处理程序。同时 UIForm 状态会自动保存。所以，当刷新这一页时，就会显示表单的原始内容。

5. 从树中提取值
在应用请求值阶段，JSF 实现遍历组件树并用 decode 方法从请求中提取值，并在本地设置每一个组件。如果在这个过程中出现了任何错误，那么它们就在 FacesContext 中排队并在呈现响应阶段显示给用户。

同时，在这个阶段排队的所有由像单击按钮这样的用户操作产生的事件，都广播给注册的侦听器。单击 reset 按钮会将文本字段中的值重新设置为它们原来的值。

6. 处理验证
在处理验证阶段，对在应用请求值阶段设置的本地值进行所有与各组件相关的验证。当 JSF 实现对每一个注册的验证器调用 validate 方法时就会进入此阶段。

如果任何一项验证失败，那么生命周期就会进入呈现响应阶段，在那里呈现带有错误信息的同一页面。在这里，所有在这一阶段排队的事件同样都会广播给注册的侦听器。

JSF 实现处理源字段上的验证器。如果数据是无效的，那么控制就交给呈现响应阶段，在这个阶段重新显示 FlightSearch.jsp 并带有相关组件的验证错误。通过在 JSP 页面中声明 output_errors， ，页面中的所有错误都会显示在页面的底部。

7. 设置模型对象值
在更新模型值阶段，成功处理了所有验证后，JSF 实现就通过对每一组件调用 updateModel 方法用有效值设置模型对象值。如果在将本地数据转换为由模型对象属性所指定的类型时出现任何错误，那么生命周期就进入呈现响应阶段，并将错误显示出来。来自表单字段属性的值会填充为模型对象的属性值。

8. 可以调用 ActionListener
可以将一个 ActionListener 与一个用户操作，如单击提交按钮相关联，如清单 1所示。在调用应用程序阶段，对 FlightSearchActionListener 调用了 processAction 方法。在实际应用中， processAction 方法在调用后会搜索数据以找出满足条件的航班，并从组件的 action 属性中提取输出。

在本文提供的这个示例 Web 应用程序中，我们使用了静态数据表示航班表。这个方法还将提取的 action 属性发送给 NavigationHandler 实现。 NavigationHandler 查询 faces-config.xml 文件 -- 这是 JSF 的默认应用程序配置文件 -- 以根据这一输出确定下一页是什么。

9. 呈现响应 在呈现响应阶段，如果在 faces 上下文中没有错误，就显示由查询配置文件得到的这一页 FlightList.jsp。如果是因为前面任一阶段的错误而到达这一阶段的，那么就会重新显示带有错误信息的 FlightSearch.jsp。

图 2. 处理一个 JSF 请求
单击这里以观看该图。

清单 1. FlightSearch.jsp，一个简单的 JSF 表单


<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>

在这段代码中使用了两个 JSF-RI 的标记库。 html_basic 标记库定义了 HTML 组件常用的标记，而 jsf-core 标记库包含用于注册侦听器和验证器的标记。其他标记有：

f:use_faces 标记向 JSF 实现表明后面的标记是 faces 标记。
f:validate_required 标记表明它所在的字段(在 FlightSearchBean 中是 fromCity 字段)在提交表单时应该有值。
h:form 和 h:input_text 标记分别表示一个名为 flightSearchForm 的 HTML 表单和各种文本字段。
h:command_button 标记用于表示提交和重设按钮。
最后， h:output_errors 标记类似于 Struts html:errors 标记，用于显示在表单字段验证中出现的任何错误。

一个名为 FlightSearchBean 的 JavaBean 表示在更新模型值阶段用 UIComponent 数据更新的模型。通常在 JSP 页中 JavaBean 是用 jsp:useBean 标记声明的。您可能注意到了在 FlightSearch.jsp 中没有这样做。这是因为可以使用 JSF 的一个名为 Managed Beans 的功能，在 faces 配置文件中声明所有 JSP 页面使用的 JavaBeans 组件。在开始时，servlet 容器会初始化这些 JavaBeans 组件。faces-config.xml 文件中的 FlightSearchBean 入口如清单 2所示：

清单 2. faces-config.xml 的 TravelInfoBean入口



  FlightSearchBean
  
    foo.bar.FlightSearchBean
  
  session

现在让我们看一看这些阶段是如何处理响应的。

呈现 faces 响应

一个 faces 响应是由 Faces 应用程序在生成包含 JSF 标记的 JSP 页时生成的。这个响应可以是 JSF 应用程序的 faces 或者 non-faces 响应。

在我们的例子中，清单 1 中页面的呈现是一个 faces 响应。您可能熟悉 Tag 接口的 doStartTag() 和 doEndTag() 方法。在 JSF 和 Struts-Faces 中，每一个标记都是从 UIComponentTag 扩展的。 UIComponentTag 实现了 doStartTag() 和 doEndTag() 方法。

它还有两个抽象方法 getComponentType() 和 getRendererType()。 通过在具体的标记类中实现这两个方法，就可以分别指定组件和 renderer 的类型。

考虑一个带有文本字段的简单 JSF 表单。在呈现 JSF 表单时执行以下一系列步骤。

1. 调用 doStartTag() 方法
Servlet 窗口对 FormTag 调用 doStartTag() 方法。

2. 得到 UIComponent
FormTag 从 getComponentType() 方法得到其 UIComponent。 UIComponentTag ( FormTag 的父组件)使用 getComponentType() 以从 faces-config.xml 文件中查询这个组件的类名，并创建 UIComponent(FormComponent )的一个实例。


3. 得到 renderer 
下一步， FormTag 从 getRendererType 方法中得到其 renderer 。与组件类型一样，renderer 名是在 faces-config.xml 文件中查询的。 
4. 调用编码方法 
在创建了 FormComponent 和 FormRenderer 后，对 FormComponent 调用 encodeBegin() 方法。每一个标记的呈现都由 encodeBegin() 开始、由 encodeEnd() 结束。 encodeBegin() 方法是按嵌套的顺序调用的。 
5. 结束标记和呈现 HTML 
servlet 容器对标记调用 doEndTag() 方法。以嵌套的反顺序对每一个组件调用 encodeEnd() 方法。在最后，表单和所有嵌套的组件都呈现为 HTML。这时，HTML 就生成完毕，并呈现出对应于 JSP 的 HTML。 
图 3 显示构成生成 faces 响应的事件序列。
图 3. 呈现一个 faces 响应 
单击这里以查看该图。 















回页首



为什么将这三者集成为一体？
随着 JSP 和相关规范的不断发展，像 JSF 和 JSP 标记库(或者 JSTL，它使用简单的标记封装许多 JSP 应用程序常用的核心功能)这样的新标准正在不断出现。下面是使用集成为一个整体的新技术一些好处：

更清晰地分离行为和展示。 将标记、 renderer 和组件分离，就可以更好地定义开发周期中的页面作者和应用程序开发人员的作用。 

改变一个组件的展示不会有雪崩效应。现在您可以容易地只对 renderer 作出改变。在传统的 MVC 模型中，由于没有这种分离，对于标记的任何改变都需要改变业务逻辑。现在再不需要这样了。 

renderer 无关性。 也可以说是协议无关性，通过对带有多个 renderer 的多种展示设备重复使用组件逻辑实现。使用不同 renderer 的能力使得不再需要对特定的设备编写整个表示层代码。 

组装和重用自定义组件的标准。JSF 的考虑范围超出了“表单和字段”，它提供了丰富的组件模型用以呈现自定义 GUI 组件。用 JSF 可以定制每一个组件在页面中的外观和行为。开发人员还拥有创建他们自己的 GUI 组件(如菜单和树)的能力，这些组件可以用简单的自定义标记容易地加入到任何 JSP 页面中。就像 AWT 和 Swing 所提供的 Java 前端 GUI 组件一样，我们可以在我们的 Web 页而中有自定义的组件，它们使用自己的事件处理程序并有定制的外观。这是 Web 层的 GUI 天堂！ 
Struts 是一种已经拥有大量客户基础的框架。许多 IT 部门认识到这种 MVC 框架的价值并使用它有一段时间了。JSF 没有像 Structs 这样强大的控制器结构，也没有像它那样标准化的 ActionForm 和 Actions （及它们声明的能力）。将 Tiles 集成到集合体中，就给了自己重复使用和以无缝的方式改变公司布局的能力。 
移植支持 JSF 的 Struts 应用程序的挑战是双重的。首先，Struts 标记不是 JSF 兼容的。换句话说，它们没有像 JSF 规范所规定的那样扩展 UIComponentTag ，所以，JSF 不能解释它们并关联到 UIComponent 和 Renderers 。 
其次，在 FacesServlet 与 Struts RequestProcessor 之间没有链接。在 Struts 应用程序中， RequestProcessor 负责用 ActionForm 和 Actions 类中的回调方法显示。 ActionForm 属性和 validate() 的 getter 和 setter 是 ActionForm 中的回调方法。对于 Action ， execute() 是回调方法。除非调用了 RequestProcessor ，否则 Struts ActionForm 和 Actions 类中的回调方法没有机会调用业务逻辑。 















回页首



将 Struts 和 JSF 与 Struts-Faces 集成
这里，您可能会问是否有软件可以帮助将 Struts 与 JSF 集成，或者是否必须自己编写集成软件。
好消息是已经有这样的软件了。 Struts-Faces 是一个早期发布的 Struts JSF 集成库。这个库是由 Craig McClanahan 创建的，它使得将现有 Struts 应用程序移植到 JSF 变得容易了(保留了对现有 Struts 投资的价值)。Struts-Faces 还力图与 JSF 进行简洁的集成，这样就可以在前端使用 JSF，同时后端仍然有熟悉的 Struts 组件。 
图 4 展示了 Struts-Faces 与 JSF 类之间的关系。蓝色的类属于 Struts-Faces。
图 4. Struts-Faces 类图 
单击这里以查看该图。 
下面是 Struts-Faces 的主要组件：

FacesRequestProcessor 类，它处理所有 faces 请求。这个类继承了常规 Struts RequestProcessor ，并处理 faces 请求。Non-faces 请求发送给出其父类 -- RequestProcessor 。 

ActionListenerImpl 类，它处理像提交表单或者单击链接这样的 ActionEvent 。这个类用于代替由 JSF-RI 提供的默认 ActionListener 实现。只要在一个 faces 请求中生成 ActionEvent ，就会对 ActionListenerImpl 调用 processAction() 方法、并将 ActionEvents 转送给 FacesRequestProcessor 。这很有意思，因为 RequestProcessor 通常只由 ActionServlet 调用以处理 HTTP 请求。 

FormComponent 类，它扩展了 JSF Form 组件，但是是在 Struts 生命周期内调用的。 

FormComponent 的 renderer 和标记。 

只用于输出的数据标记和 renderer ，这里不需要分离组件。例如， ErrorsTag 和 ErrorsRenderer 用于在 HTML 中显示表单错误。 

ServletContextListener 的名为 LifeCycleListener 的实现。它用于在初始化时注册相应的 RequestProcessor 。 

faces-config.xml 文件。这个文件已经捆绑在 struts-faces.jar 文件中。 
清单 3 展示了使用 Struts-Faces 标记的 FlightSearch.jsp。它类似于在 清单 1中展示的 JSF 例子。这里用粗体突出了区别之处。在这里，您会发现增加了一个新标记库 tags-faces。这个标记库定义声明这些标记由 Struts-Faces API 所使用。 

清单 3. FlightSearch.jsp 使用 Struts-Faces 标记





<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://jakarta.apache.org/struts/tags-faces" 
  prefix="s" %> 


    
     

     
     
     

     
     

     
    



s:form 标记用于创建这个 HTML 表单。表单的 action 属性是 /listFlights而不是像 清单 1那样指定为表单名 flightForm。在 JSF 中，表单名只是指定给 UIForm 的名字而没有更多的意义。 
FlightSearchBean 是 JSF 表单的模型，并在更新模型值阶段得到其值。不过在 Struts 中，表单 action 指向 Struts 配置文件 struts-config.xml 中的 ActionMapping 。为了理解它是如何起作用的，还必须看一下清单 4 中显示的 struts-config.xml 文件。 
您会看到 /listFlights 的 ActionMapping 表明这个 URI 路径的 ActionForm 是 foo.bar.FlightSearchForm ，而 Action 类是 foo.bar.FlightSearchAction 。换句话说， ActionForm ( FlightSearchForm )本身就是 Struts-Faces 中的 HTML 表单的模型，它的 action 间接地指向这个模型(您可以在清单 3 中看到这一点，那里文本字段标记指向 FlightSearchForm 。在普通 Struts 应用程序中这会是  )。 

清单 4. 在 struts-config.xml 中声明 Action











 
    
 




您会注意到在 action 属性中缺少熟悉的 .do。这是因为 Struts-Faces 使用表单 action 本身作为表单名(它还应该与 Struts 配置文件中的 ActionForm 名相匹配)。 








集成 Struts 和 Tiles 的五个步骤

以下五步可以让 Struts 1.1 和 Tiles 共同工作： 
1. 创建一个 JSP 以表示站点的布局。这是主 JSP，并带有页头、页体和页脚的占位符。分别用 Tiles 标记添加到主 JSP 页面中。 
2. 创建一个 Tiles 定义文件并定义每个集成页面的每个占位符中必须包括哪个 JSP 页面。用惟一的名称标识出每一个合成页面定义。 
3. 在 struts-config.xml 文件中改变全局和本地转发以使用上一步骤中给出的惟一名称而不是别名。 
4. 在启动时用 TilesPlugIn 装载 Tiles 定义文件。将 TilesPlugIn 项加入到 struts-config.xml 文件中。 
5. 将 TilesRequestProcessor 项添加到 struts-config.xml 文件中。这是支持 Tiles 的 Struts 应用程序的默认请求处理程序。 
还要注意我们在这里没有使用 JSF validation 标记。这是因为在 Struts 中，验证是在 ActionForm 类中的 validate() 方法中进行的，有可能是通过使用 Commons-Validator。 s:errors 标记类似于 Struts 错误标记并用于显示在验证时出现的错误消息。 

另一件要注意的事情是没有 ActionListener 显式地与提交按钮相关联。这是因为在 Struts-Faces 中已经提供了 ActionListener 并且总是将 faces 请求与 ActionEvent s 一同转交给 FacesRequestProcessor ，在那里根据 struts-config.xml 文件将请求分派给相应的 Action 类。 















回页首



将Struts 应用程序移植到 JSF
为了将 Struts Web 应用程序与 JSF 集成，遵循以下步骤：

将 struts-faces.jar 文件与特定于 JSF 的 JAR(jsf-api.jar、jsf-ri.jar) 添加到 Web 应用程序的 WEB-INF/lib目录中。 

如果准备使用 JSF 和 JSTL，则将特定于 JSTL 的 JAR(jstl.jar、standard.jar)添加到 WEB-INF/lib 文件夹中。这一步只有在部署到常规 Tomcat 时才会需要。JWSDP 已经提供了这些 JAR。 

修改 Web 应用程序部署描述符 ( /WEB-INF/web.xml)以便有一个 Faces Servlet 项， 如清单 5 所示。 

修改 JSP 页面以使用 JSF 和 Struts-Faces 标记而不是 Struts 标记。特别是用 Struts-Faces 相应标记替换 html、b ase、 form 和 errors 标记。用 JSF 相应标记替换 text 、 textarea 和 radio 标记。Struts-Faces 没有单独针对这些的标记。尽管没有要求，但是您可能还会考虑用 JSTL 标记替换 Struts Logic 标记。 

对于每一个使用 JSF 标记的 JSP，修改 struts-config.xml 文件以在指向该 JSP 的 Action Mapping 中的 global-forwards和 local-forwards中加入前缀 /faces。 

如果 Web 应用程序使用了任何您创建的自定义组件，那么您就需要用 JSF 实现的默认 RenderKit 注册它们。可以通过在 WEB-INF 文件中创建一个 faces-config.xml 文件、并增加每一个组件和 renderer 的项做到这一点。不过，要记住 faces-config.xml 文件已经绑定在 struts-faces.jar 文件中了。您必须从 struts-faces.jar 文件中提出它、加入自己的内容并将它放到 WEB-INF文件夹中。 

清单 5. 在 web.xml 中声明 FacesServlet







faces
javax.faces.webapp.FacesServlet
1




  faces
  /faces/*

















回页首



集成 Struts-Faces 和 Tiles 的挑战
Struts-Faces 库提供了 Struts 与 JSF 之间的一个高效的桥梁，使得在 J2EE Web 应用程序中拥有丰富的表示层成为现实。您可以通过在组合体中添加 Titles 使表示层更丰富，这样不仅得到了 Struts 和 JSF 组合的好处，而且还可以高效地重复使用不同的 JSP 页面，因为它们将由可以根据需要添加或者删除的组件部分或者 tiles 所构成。
本文已经展示了 Struts 和 JSP 的集成，您会想将 Tiles 加入到组合中只是小事一桩，是不是？
不幸的是，JSF 仍然处于早期阶段，还没有给出最后的发布。基于这一考虑，Struts-Faces 集成软件开发仍然在不断地发展以包括 JSF 的不同的功能，并且还没有支持 Tiles。
Struts 和 Tiles 可以无缝地共同工作，但是在集成之路上您会遇到路障。在下面几小节中，您会看到在与 Tiles 共同使用 Struts-Faces 集成库时经常遇到的问题的汇总。对于每一个问题，我们详细说明了一个修改 Struts-Faces 类的解决方案。我们将用一个航班搜索示例解释这个解决方案。
清单 6 展示了航班搜索页面的布局。注意我们称它为航班搜索页面而不是 FlightSearch.jsp。这是因为 FlightSearch JSP 是用户在 foobar 旅行 Web 站点看到的合成页面的主体。
现在，我们保持实际的 FlightSearch.jsp 不变。我们将随着进展改变它。在您这边，也需要用航班搜索页的定义创建一个 Tiles 定义文件。清单 7(紧接着清单 6)展示了 Tiles 定义文件中航班搜索页的一项。注意对带有 extends 属性的主布局模板的重复使用。 
在清单 6 和 7 后是每一个可能的挑战。

清单 6. 航班搜索例子的 Tiles 布局





<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %>
<%@ taglib uri="http://jakarta.apache.org/struts/tags-faces"prefix="s" %>




   <tiles:getAsString name="title"/>
  


  
    
     
    

    
     
    

    

    
     
    
  





清单 7. 航班搜索页的 Tiles 定义







      
      
      
      


  

      


响应已经提交
这是您在试图访问航班搜索表单时马上会看到的第一个问题。小心查看堆栈跟踪。您会看到问题出在类 com.sun.faces.lifecycle.ViewHandlerImpl 上。这是一个实现了 ViewHandler 接口的 JSF-RI 类。 
图 2展示了 ViewHandler 所扮演的角色。这是一个将请求转发给下一页的类。在转发请求时，它不在转发前检查响应的状态 -- 这只有在使用 Tiles 时才会发生，因为 Tiles 内部将 JSP 页面包括在响应内，而 JSF-RI 在第一次转发后提交响应、然后试图再次转发给下面的包括 JSP 的 Tiles。 
要解决这个问题，必须创建一个自定义的 ViewHandler 实现，它将检查响应的状态以确定它是否提交过。如果响应没有提交过，那么请求就转发给下一页，否则，就加入请求并显示相应的 JSP。我们将创建一个名为 STFViewHandlerImpl 的类，它实现了 ViewHandler 接口并实现了所需要的方法 renderView()。 清单 8 展示了 STFViewHandlerImpl 中的 renderView() 方法： 

清单 8. STFViewHandlerImpl 中的 renderView()方法





RequestDispatcher rd = null;
Tree tree = context.getTree();
String requestURI = context.getTree().getTreeId();
rd = request.getRequestDispatcher(requestURI);

/** If the response is committed, include the resource **/
if( !response.isCommitted() ) {
   rd.forward(request, context.getServletResponse());
}
else {
   rd.include(request, context.getServletResponse());
}


现在您实现了自己的 ViewHandler ，如何通知 JSF-RI 使用您的 ViewHandler 而不是默认的实现呢？要回答这个问题，就必须理解 FacesServlet 的工作过程。 
在 Faces 初始化过程中， FacesServlet 会让 LifecycleFactory 实现返回 Lifecycle 类的一个实现，如清单 9 所示： 

清单 9. FacesServlet 中 Faces 的初始化





//Get the LifecycleFactory from the Factory Finder
LifecycleFactory factory = (LifecycleFactory) 
  FactoryFinder.getFactory("javax.faces.lifecycle.LifecycleFactory");

//Get the context param from web.xml
String lifecycleID = 
getServletContext().getInitParameter("javax.faces.lifecycle.LIFECYCLE_ID");

//Get the Lifecycle Implementation
Lifecycle lifecycle = factory.getLifecycle(lifeCycleID);


Lifecycle 实现对象拥有在呈现响应阶段要使用的 ViewHandler 。您可以通过对 Lifecycle 实现调用 setViewHandler 方法让自己的 ViewHandler 实现成为默认的。 
现在问题变为如何得到默认 Lifecycle 实现？回答是不需要这样做。只要创建一个新的实现并用一个惟一 ID 注册它，如清单 10 所示： 

清单 10. 注册自定义 ViewHandler 和 Lifecycle





//Get the LifecycleFactory from the Factory Finder
LifecycleFactory factory = (LifecycleFactory) 
  FactoryFinder.getFactory("javax.faces.lifecycle.LifecycleFactory");

//Create a new instance of Lifecycle implementation - 
//com.sun.faces.lifecycle.LifecycleImpl
//According to the documentation, factory.getLifecycle("STFLifecycle") 
//should work, but JSF-RI has a defect.
//Hence this workaround of creating a RI class explicitly.
LifecycleImpl stfLifecycleImpl = new LifecycleImpl();

//Create a new instance of our STFViewHandler and set it on the Lifecycle
stfLifecycleImpl.setViewHandler(new STFViewHandlerImpl());

//Register the new lifecycle with the factory with a unique 
//name "STFLifecycle"
factory.addLifecycle("STFLifecycle", stfLifecycleImpl);


您可以看到 lifecycleId 硬编码为 STFLifecycle 。实际上不是这样。当您回过头分析 清单 9时就会清楚。 FacesServlet 从在 web.xml 文件中声明的上下文参数中得到名为 javax.faces.lifecycle.LIFECYCLE_ID 的 lifecycle ID，如下所示： 




    
        javax.faces.lifecycle.LIFECYCLE_ID
        STFLifecycle
    


因为 FacesServlet 取决于其初始化时的 Lifecycle 实现，在 清单 10中展示的代码应该在 FacesServlet 初始化之前执行。通过创建另一个 servlet 并在 FacesServlet 之前初始化它而做到这一点。 
但是一种更聪明的办法是实现一个 ServletContextListener 接口。这个类声明两个方法： contextInitialized() 和 contextDestroyed() ，在 Web 应用程序被创建及 Web 应用程序被销毁之前会分别调用它们。因而 清单 10中的代码在 contextInitialized() 方法中执行，而自定义 ViewHandler 已经用标识名 STFLifecycle 注册到 Lifecycle ，并且可被 FacesServlet 使用。 ServletContextListener 类本身是在 web.xml 文件中声明的，如下所示： 





  foo.bar.stf.application.STFContextListener
  



这不是注册一个带有自定义 ViewHandler 的 Lifecycle 惟一方法。事实上 FactoryFinder 实现了自己的发现算法以发现 Factory 对象，包括 LifecycleFactory 。这些机制按照顺序包括在系统属性中查看工厂实现类名的机制、faces.properties file、或者 1.3 Services 发现机制( META-INF/services/{factory-class-name} )。不过，我们讨论的这种机制是最容易的，也是最不具有破坏性的一种。 
404 Resource Not Found
在解决了提交响应的问题后，单击任何一个 Tiles 特定的链接或者输入一个会呈现 Faces 响应的 URL。在这里，可以输入显示 FlightSearchForm 的 URL。 
在这样做了以后，您会得到一个 foobar.flight-search - 404 Resource Not Found 错误。 foobar.flight-search 是航班搜索页面的 Tiles 定义的名字。 FacesRequestProcessor 不能处理 Tiles 请求(因为它扩展的是 RequestProcessor 而不是 TilesRequestProcessor )，所以会得到错误。 
为解决这个问题，我们将创建一个名为 STFRequestProcessor (表示 Struts-Tiles-Faces Request Processor)的新的请求处理程序。现在我们将拷贝 FacesRequestProcessor 的所有代码到这个新类中。惟一的区别是 STFRequestProcessor 继承的是 TilesRequestProcessor 而不是继承常规的 RequestProcessor 。这个新的 RequestProcessor 可以处理 Tiles 请求。清单 11 详细列出了这个 STFRequestProcessor ： 

清单 11. STFRequestProcessor.java

正如您所知道的， Struts 框架的 RequestProcessor 是在 struts-config.xml 文件中指定的。将下面的项添加到 struts-cinfig.xml 文件中后， STFRequestProcessor 就成为处理程序： 







表单提交显示返回同一个表单
由于 STFRequestProcessor 的作用，这时您就可以浏览并查看航班页面了。不过，在提交航班搜索表单时，您会得到返回来的同一个表单，而且没有页头和页脚！并且没有验证错误。事实上，根本就没有进行验证！ 
为了了解到底发生了什么事情，我们用浏览器回到航班页面并检查 HTML 源代码。您会看到像下面这样的一项：







注意表单 action 是指向 JSP 页而不是一个 .do 的。啊哈！这就是问题！这不是由于同时使用 Tiles 和 Struts-Faces 而带来的新问题，Struts-Faces 的默认行为是让 JSP 与表单 action 有同样的名字。这种行为在有单一的 JSP 页(如在前面的 Struts-Faces 例子中)时没有问题。 清单 3展示了原来的 FlightSearch.jsp，让我们继续并像下面这样修改 action： 




图 3相同，除了在 FormComponent 中突出显示的方法 createActionForm()。 由 Struts-Faces API 提供的 FormComponent 类是 javax.faces.component.UIForm 的特殊子类，它支持请求或者会话范围的表单 Bean。 
图 5. 呈现 Struts-Faces 响应 
单击这里以查看该图。 
正如您所看到的， createActionForm() 方法使用 action 名以从 Struts 配置文件中得到 ActionMapping 。因为没有对于 /listFlights.do 的 ActionMapping ，所以 Struts 不能找到 ActionForm。 
这个问题的解决方法是使用 org.apache.struts.util.RequestUtils 。 RequestUtils 中的 static 方法 getActionMappingName() 具有足够的智能解析映射到正确 ActionMapping 的路径( /x/y/z)或者后缀( .do)。 
清单 12 以粗体显示对 createActionForm 方法的改变。我们没有对 Struts-Faces 中的 FormComponent 作这些改变，而是通过继承 FormComponent 并覆盖 createActionForm() 方法创建了一个新的 STFFormComponent。 

清单 12. FormComponent 中修改过的 createActionForm() 方法





// Look up the application module configuration information we need
ModuleConfig moduleConfig = lookupModuleConfig(context);

// Look up the ActionConfig we are processing
String action = getAction();
String mappingName = RequestUtils.getActionMappingName(action);
ActionConfig actionConfig = moduleConfig.findActionConfig(mappingName);
....
....


对新的 STFFormComponent 还要作一项改变。Struts-Faces 将 action 名本身作为表单名。这需要改变，因为 action 带有后缀 .do，而表单名没有后缀 .do。所以我们在 STFFormComponent 上增加一个名为 action 的新属性，并覆盖 getAction() 和 setAction() 方法。 

FormRenderer 的改变
必须对 FormRenderer (以 HTML 格式呈现 Struts-Faces 表单的类)的 encodeBegin 方法进行类似于 清单 10所示的修改。 
同样，通过继承 FormRenderer 做到这一点。此外，还必须改变写出到 HTML 的表单 action。清单 13以粗体详细列出了这些改变： 

清单 13. FormRenderer 的改变





protected String action(FacesContext context, UIComponent component) {

    String treeId = context.getTree().getTreeId();
    StringBuffer sb = new StringBuffer 
      (context.getExternalContext().getRequestContextPath());
    sb.append("/faces");

    // sb.append(treeId); -- This is old code, replaced with 
    // the two lines below.

    STFFormComponent fComponent = (STFFormComponent) component;
    sb.append(fComponent.getAction());
    
    return (context.getExternalContext().encodeURL(sb.toString()));
}


FormTag的改变 
正如您已经知道的，当组件和 renderer 改变时，标记也必须改变。在这里，通过继承 Struts-Faces 中的 FormTag 创建一个新的标记： STFFormTag 。不必改变任何功能，只要覆盖 getComponentType() 和 getRendererType() 方法。清单 14 展示了从 STFFormComponent 覆盖的方法： 

清单 14. FormTag 的改变





public String getComponentType()
{
    return ("STFFormComponent");
}

public String getRendererType()
{
    return ("STFFormRenderer");
}


修改 faces-config.xml 文件
自定义组件和 renderer 必须在 faces-config.xml 文件中声明，这样 JSF 框架才可以初始化并使用它们。现在我们已经创建了一个新组件 STFFormComponent 和一个新 renderer STFFormRenderer 。 
现在我们将在 faces-config.xml 文件中增加一个声明，如清单 15 所示。 component-class 是组件的完全限定类名。 component-type 指的是在 STFFormTag ( 清单 12)中用于标识组件的名字。以类似的方式发现和解释 renderer。注意 faces-config.xml 文件是在 struts-faces.jar 文件中的。从 struts-faces.jar 文件中取出这个文件并将它放到 Web 应用程序的 WEB-INF文件夹中并修改它。 

清单 15. 在 faces-config.xml 中声明自定义组件和 renderer







  
  
    STFFormComponent
    
      foobar.stf.component.STFFormComponent
    
  
  ..
  ..
  ..
  
  

    
      STFFormRenderer
      
        foobar.stf.renderer.STFFormRenderer
      
    
    ..
    ..
    ..
  



修改 struts-faces.tld 文件
您不会在这个示例 Struts-Faces 应用程序中看到 struts-faces.tld 文件，它打包到了 struts-faces.jar 文件中。打开并分析这个文件。它声明了一个名为 org.apache.struts.faces.taglib.LifecycleListener 的类，这个类实现了 ServletContextListener 并初始化 FacesRequestProcessor 。 
因为希望使用新的 STFRequestProccessor ，所以必须将这个文件从 struts-faces.jar 文件中删除，将它放到 Web 应用程序的 WEB-INF 文件夹中，并删除侦听器声明。如果让这个 tld 文件保持原样，那么在初始化这个 Web 应用程序时，除了 STFRequestProcessor ，还会实例化一个 FacesRequestProcessor。 
修改 base href 标记 
现在，您已经完成了 Struts、Tiles、JSF 集成的最困难的部分了。您甚至可以浏览航班搜索页面，并输入搜索标准查看航班列表。现在试着从航班列表页面返回航班搜索表单。您会得到一个 HTTP 400 错误。这个错误的原因是 HTML base href 标记。它被设置为 Master Layout 页面。 






           |_________|       |_____________________|
              Context               Servlet Path


程序所有页面浏览都是相对于布局页面计算的。如果加入的 base href 标记只达到 Web 应用程序上下文则会很方便，像这样： 







我们可以通过定制 Struts-Faces BaseTag 做到这一点。这个类中的改变相当微不足道。只须在 base href 中去掉 HttpServletRequest.getServletPath() 。 
因为这些改变是与显示相关的，所以为它创建了一个名为 STFBaseRenderer 的新 renderer。这个新标记称为 STFBaseTag ，它声明 STFBaseRenderer 作为其关联的 renderer。不需要新的组件。 
有了这些信息，通过继承 BaseTag 并覆盖 getRendererType 方法创建新的 STFBaseTag ，如下所示： 




public String getRendererType()
{
    return ("STFBaseRenderer");
}
















回页首



到目前为止所作的改变
恭喜！经过这些相对较小的修改，您已经成功地集成了 Struts、Tiles 和 JSF，并保留了您以前在这些技术上所做的所有投资。本文演示了如何将 JSF 强大的前端能力、 Tiles 的内容格式编排优势以及 Struts 控制器层的灵活性结合在一个包中，使得创建一个 J2EE Web 应用程序成为一项更容易的任务。
我们讨论了定制 Struts 类以便与 JavaServer Faces 和 Tiles 框架形成紧密集成的工作关系，包括下面这些修改和增加：

新的 ViewHandler ，用于检查提交的响应。 

新的 ServletContextListener ，用于创建新的 Lifecycle 实现并注册这个定制的 ViewHandler。 

新的 RequestProcessor ，用于处理 Tiles 请求。 

修改过的 web.xml 文件，声明新的 ServletContextListener 和 JSF Lifecycle ID。 

新的 FormTag、 FormComponent 和 FormRenderer 类。 

新的 BaseTag 和 BaseRenderer 类。 

修改过的 faces-config.xml 文件，它声明了新的组件和 renderer。 
修改过的 struts-faces.tld 文件，不声明侦听器。 
希望它可以概括本文中使用的复合技术，最重要的是，我们为您提供了将 Struts、Tiles 和 JavaServer Faces 结合到用于构建 Web 应用程序的一个强大而灵活的机制中的一个令人信服的路线图。
代码下载

☆蓝色梦想☆ 2005-12-08 09:26 发表评论