| JSF 简介 |  | | 为什么将这三者集成为一体？ | | | 将 Struts 和 JSF 与 Struts-Faces 集成 | | | 将Struts 应用程序移植到 JSF | | | 集成 Struts-Faces 和 Tiles 的挑战 | | | 到目前为止所作的改变 | |
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<f:use_faces>
<h:form id="flightForm" formName="flightForm" >
<h:input_text id="fromCity" valueRef="FlightSearchBean.fromCity">
<f:validate_required/>
<h:input_text/>
<h:input_text id="toCity" valueRef="FlightSearchBean.toCity">
<h:input_text id="departureDate"
valueRef="FlightSearchBean.departureDate">
<h:input_text id="arrivalDate"
valueRef="FlightSearchBean.arrivalDate">
<h:command_button id="submit" action="success"
label="Submit" commandName="submit" >
<f:action_listener
type="foo.bar.FlightSearchActionListener"/>
</h:command_button>
<h:command_button id="reset" action="reset" label="Reset"
commandName="reset" />
<h:output_errors/>
</h:form>
</f:use_faces>
在这段代码中使用了两个 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入口
<managed-bean>
<managed-bean-name>FlightSearchBean</managed-bean-name>
<managed-bean-class>
foo.bar.FlightSearchBean
</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
|
现在让我们看一看这些阶段是如何处理响应的。 呈现 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" %>
<f:use_faces>
<s:form action="/listFlights">
<h:input_text id="fromCity" valueRef="FlightSearchForm.fromCity"/>
<h:input_text id="toCity" valueRef="FlightSearchForm.toCity"/>
<h:input_text id="departureDate"
valueRef="FlightSearchForm.departureDate">
<h:input_text id="arrivalDate"
valueRef="FlightSearchForm.arrivalDate">
<h:command_button id="submit" action="success" label="Submit"
commandName="submit" />
<h:command_button id="reset" action="reset" label="Reset"
commandName="reset" />
<s:errors/>
</s:form>
</f:use_faces>
|
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 应用程序中这会是 <html:text property="fromCity"/> )。 清单 4. 在 struts-config.xml 中声明 Action
<form-bean name="FlightSearchForm"
type="foo.bar.FlightSearchForm"/>
<!-- ========== Action Mapping Definition ========================= -->
<action-mappings>
<!-- List Flights action -->
<action path="/listFlights"
type="foo.bar.FlightSearchAction"
name="FlightSearchForm"
scope="request"
input="/faces/FlightSearch.jsp">
<forward name="success" path="/faces/FlightList.jsp"/>
</action>
</action-mappings>
|
您会注意到在 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() 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
<!-- JavaServer Faces Servlet Configuration -->
<servlet>
<servlet-name>faces</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<!-- JavaServer Faces Servlet Mapping -->
<servlet-mapping>
<servlet-name>faces</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
|
集成 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" %>
<!-- Layout component parameters: header, menu, body, footer -->
<s:html>
<head>
<title> <tiles:getAsString name="title"/></title>
<s:base/>
</head>
<body>
<TABLE border="0" width="100%" cellspacing="5">
<tr>
<td><tiles:insert attribute="header"/></td>
</tr>
<tr>
<td><tiles:insert attribute="body"/></td>
</tr>
<tr><td><hr></td></tr>
<tr>
<td><tiles:insert attribute="footer" /></td>
</tr>
</TABLE>
</body>
</s:html>
|
清单 7. 航班搜索页的 Tiles 定义
<!-- Master Layout definition -->
<definition name="foobar.master-layout"
path="/faces/layout/MasterLayout.jsp">
<put name="title" value="Welcome to Foo Bar Travels" />
<put name="header" value="/faces/common/header.jsp" />
<put name="footer" value="/faces/common/footer.jsp" />
<put name="body" value="" />
</definition>
<!-- Definition for Flight Search Page -->
<definition name="/foobar.flight-search"
extends="foobar.master-layout">
<put name="body" value="/faces/FlightSearch.jsp" />
</definition> |
响应已经提交
这是您在试图访问航班搜索表单时马上会看到的第一个问题。小心查看堆栈跟踪。您会看到问题出在类 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，如下所示：
<context-param>
<param-name>javax.faces.lifecycle.LIFECYCLE_ID</param-name>
<param-value>STFLifecycle</param-value>
</context-param>
|
因为 FacesServlet 取决于其初始化时的 Lifecycle 实现，在 清单 10中展示的代码应该在 FacesServlet 初始化之前执行。通过创建另一个 servlet 并在 FacesServlet 之前初始化它而做到这一点。 但是一种更聪明的办法是实现一个 ServletContextListener 接口。这个类声明两个方法： contextInitialized() 和 contextDestroyed() ，在 Web 应用程序被创建及 Web 应用程序被销毁之前会分别调用它们。因而 清单 10中的代码在 contextInitialized() 方法中执行，而自定义 ViewHandler 已经用标识名 STFLifecycle 注册到 Lifecycle ，并且可被 FacesServlet 使用。 ServletContextListener 类本身是在 web.xml 文件中声明的，如下所示：
<listener>
<listener-class>foo.bar.stf.application.STFContextListener
</listener-class>
</listener>
|
这不是注册一个带有自定义 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 就成为处理程序：
<controller processorClass="foobar.stf.application.STFRequestProcessor" />
|
表单提交显示返回同一个表单
由于 STFRequestProcessor 的作用，这时您就可以浏览并查看航班页面了。不过，在提交航班搜索表单时，您会得到返回来的同一个表单，而且没有页头和页脚！并且没有验证错误。事实上，根本就没有进行验证！ 为了了解到底发生了什么事情，我们用浏览器回到航班页面并检查 HTML 源代码。您会看到像下面这样的一项：
<form name="FlightSearchForm" method="post"
action="/flightapp/faces/FlightSearch.jsp">
|
注意表单 action 是指向 JSP 页而不是一个 .do 的。啊哈！这就是问题！这不是由于同时使用 Tiles 和 Struts-Faces 而带来的新问题，Struts-Faces 的默认行为是让 JSP 与表单 action 有同样的名字。这种行为在有单一的 JSP 页(如在前面的 Struts-Faces 例子中)时没有问题。 清单 3展示了原来的 FlightSearch.jsp，让我们继续并像下面这样修改 action：
<s:form action="/listFlights.do>
|
当然，光有这种修改并不能解决问题。作了这种改变后，您就会发现 STFRequestProcessor 不能找到 ActionForm 。显然还需要其他的改变。 不过，在继续往下之前，看一下图  5。它显示了在呈现负责 Struts-Faces 表单的 faces 时相关的一系列事件。这与 图 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
<faces-config>
<!-- Custom Components -->
<component>
<component-type>STFFormComponent</component-type>
<component-class>
foobar.stf.component.STFFormComponent
</component-class>
</component>
..
..
..
<!-- Custom Renderers -->
<render-kit>
<renderer>
<renderer-type>STFFormRenderer</renderer-type>
<renderer-class>
foobar.stf.renderer.STFFormRenderer
</renderer-class>
</renderer>
..
..
..
</render-kit>
</faces-config>
|
修改 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 页面。
<base href=http://www.pcround.cn/5/7/2007-11-04/"http://localhost:8080/stf-example/faces/layout/MasterLayout.jsp" />
|_________| |_____________________|
Context Servlet Path
|
程序所有页面浏览都是相对于布局页面计算的。如果加入的 base href 标记只达到 Web 应用程序上下文则会很方便，像这样：
<base href=http://www.pcround.cn/5/7/2007-11-04/"http://localhost:8080/stf-example/" />
|
我们可以通过定制 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 应用程序的一个强大而灵活的机制中的一个令人信服的路线图。 参考资料 - 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
- 下载本文的 例子和代码，并遵循 README.txt 中给出的编译和部署的说明。
- Ant 用于对例子进行编译，可以从 Apache Ant 项目Web 站点下载它。
- 有关 Struts 和 Tiles 的更多内容，包括可下载的教程、文档、二进制文件和源代码，可从 Apache Jakarta Project StrutsWeb 站点获得。
- 可以将 JSF Early Acess Release 4 (EA4) 作为 Java Web Services Developer Pack Version 1.2 的一部分下载 -- 它带有自己版本的 Tomcat。
- 可以从 Jakarta 站点下载 Struts-Faces integration library的 0.3 和 0.4 版本。
- 可以从 Java Web Services Developer Pack 1.2 下载 JSF-RI。
- “ Struts, an open-source MVC implementation”( developerWorks， 2001年2月)介绍了 Struts，这是一个使用了 servlets 和 JavaServer Pages 技术的模型-视图-控制器实现。
- “ Struts and Tiles aid component-based development”( developerWorks，2002年6月)解释了为什么结合 Struts 和 Tiles 可以成为创建 Web 应用程序的出色软件包，并展示了如何使用它，侧重于 Struts 0.9 之后的改变。
- “ Struttin' your stuff with WebSphere Studio Application Developer, Part 2: Tiles” ( developerWorks，2002年11月)是一个教程，主要关注在使用 WebShpere Studio Application Developer 作为开发环境时结合 Struts 使用 Tiles 模型框架。
- “ Architect Struts applications for Web services”( developerWorks，2003年4月)展示了如何基于 MVB 设计模式用 Struts 建立 Web 服务应用程序。
- “ A JSTL primer”( developerWorks，2003年2-5月)，这是一个分为四部分的系列，提供了有关 JSTL 的所有内容，包括如何使用 JSTL 标记以避免在 JSP 页面中使用脚本元素、如何通过删除表示层中的代码简化软件维护、以及 JSTL 的简化的表达式语言，它使得无需使用全功能的编程语言就可以为 JSTL action 指定动态属性值。
- 学习用 JSF 开发 Web 应用程序的基本内容。在其教程“ UI development with JavaServer Faces” ( developerWorks，2003年9月)中，Jackwind Li Guojie 探讨了 JSF 生命周期、输入验证、事件处理、页面浏览和国际化。
- Sun 的 JSF Web 站点是另一个很好的学习有关 JavaServer Faces 技术的起点。
- ServerSide.com J2EE 社区是查找有关 J2EE 的资源及参加开发者论坛的理想地点。
- 在 Java Community Process站点可以迅速得到有关 JavaServer Pages 1.2 规范的内容。
- 在 developerWorks Java 技术专区 可以找到关于 Java 编程各方面的数百篇文章。
作者简介
 Srikanth Shenoy 专门从事大型 J2EE 和 EAI 项目的体系结构、设计、开发和部署工作。Srikanth 已经帮他的制造业、物流业和金融业客户实现了 Java 平台“一次编写，随处运行”的梦想。他是 Sun 认证的企业架构师，并且是即将出版的 Practical Guide to J2EE Web Projects一书的作者之一。可以通过 srikanth@srikanth.org与他联系。 |
 Nithin Mallya 专门为金融客户提供企业级解决方案。他有七年架构和开发服务器端解决方案的经验，大多数是 Java 平台。他是 Sun 认证的企业架构师，并且是 Sun 认证的 Web 组件开发者。他也是即将出版的 Practical Guide to J2EE Web Projects一书的作者之一。可以通过 nithin@mallya.org 与他联系。
|
| 
