为了将 Struts Web 应用程序与 JSF 集成,遵循以下步骤:
html、b
ase、
form
和 errors
标记。用 JSF 相应标记替换 text
、 textarea
和 radio
标记。Struts-Faces 没有单独针对这些的标记。尽管没有要求,但是您可能还会考虑用 JSTL 标记替换 Struts Logic 标记。
清单 5. 在 web.xml 中声明 FacesServlet
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 后是每一个可能的挑战。
这是您在试图访问航班搜索表单时马上会看到的第一个问题。小心查看堆栈跟踪。您会看到问题出在类 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()
方法:
现在您实现了自己的 ViewHandler
,如何通知 JSF-RI 使用您的 ViewHandler
而不是默认的实现呢?要回答这个问题,就必须理解 FacesServlet
的工作过程。
在 Faces 初始化过程中, FacesServlet
会让 LifecycleFactory
实现返回 Lifecycle
类的一个实现,如清单 9 所示:
清单 9. FacesServlet 中 Faces 的初始化
Lifecycle
实现对象拥有在呈现响应阶段要使用的 ViewHandler
。您可以通过对 Lifecycle
实现调用 setViewHandler
方法让自己的 ViewHandler
实现成为默认的。
现在问题变为如何得到默认 Lifecycle
实现?回答是不需要这样做。只要创建一个新的实现并用一个惟一 ID 注册它,如清单 10 所示:
清单 10. 注册自定义 ViewHandler 和 Lifecycle
lifecycleId
硬编码为
STFLifecycle
。实际上不是这样。当您回过头分析
清单 9时就会清楚。
FacesServlet
从在 web.xml 文件中声明的上下文参数中得到名为
javax.faces.lifecycle.LIFECYCLE_ID
的 lifecycle ID,如下所示:
因为 FacesServlet
取决于其初始化时的 Lifecycle
实现,在 清单 10中展示的代码应该在 FacesServlet
初始化之前执行。通过创建另一个 servlet 并在 FacesServlet
之前初始化它而做到这一点。
但是一种更聪明的办法是实现一个 ServletContextListener
接口。这个类声明两个方法: contextInitialized()
和 contextDestroyed()
,在 Web 应用程序被创建及 Web 应用程序被销毁之前会分别调用它们。因而 清单 10中的代码在 contextInitialized()
方法中执行,而自定义 ViewHandler
已经用标识名 STFLifecycle
注册到 Lifecycle
,并且可被 FacesServlet
使用。 ServletContextListener
类本身是在 web.xml 文件中声明的,如下所示:
这不是注册一个带有自定义 ViewHandler
的 Lifecycle
惟一方法。事实上 FactoryFinder
实现了自己的发现算法以发现 Factory
对象,包括 LifecycleFactory
。这些机制按照顺序包括在系统属性中查看工厂实现类名的机制、faces.properties file、或者 1.3 Services 发现机制( META-INF/services/{factory-class-name}
)。不过,我们讨论的这种机制是最容易的,也是最不具有破坏性的一种。
在解决了提交响应的问题后,单击任何一个 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 源代码。您会看到像下面这样的一项:
|
注意表单 action 是指向 JSP 页而不是一个 .do 的。啊哈!这就是问题!这不是由于同时使用 Tiles 和 Struts-Faces 而带来的新问题,Struts-Faces 的默认行为是让 JSP 与表单 action 有同样的名字。这种行为在有单一的 JSP 页(如在前面的 Struts-Faces 例子中)时没有问题。 清单 3展示了原来的 FlightSearch.jsp,让我们继续并像下面这样修改 action:
|
当然,光有这种修改并不能解决问题。作了这种改变后,您就会发现 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() 方法
|
对新的 STFFormComponent
还要作一项改变。Struts-Faces 将 action 名本身作为表单名。这需要改变,因为 action 带有后缀 .do,而表单名没有后缀 .do。所以我们在 STFFormComponent
上增加一个名为 action
的新属性,并覆盖 getAction()
和 setAction()
方法。
必须对 FormRenderer
(以 HTML 格式呈现 Struts-Faces 表单的类)的 encodeBegin
方法进行类似于 清单 10所示的修改。
同样,通过继承 FormRenderer
做到这一点。此外,还必须改变写出到 HTML 的表单 action。清单 13以粗体详细列出了这些改变:
|
FormTag的改变
正如您已经知道的,当组件和 renderer 改变时,标记也必须改变。在这里,通过继承 Struts-Faces 中的 FormTag
创建一个新的标记: STFFormTag
。不必改变任何功能,只要覆盖 getComponentType()
和 getRendererType()
方法。清单 14 展示了从 STFFormComponent
覆盖的方法:
|
自定义组件和 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
|
您不会在这个示例 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
标记只达到 Web 应用程序上下文则会很方便,像这样:
|
我们可以通过定制 Struts-Faces BaseTag
做到这一点。这个类中的改变相当微不足道。只须在 base href 中去掉 HttpServletRequest.getServletPath()
。
因为这些改变是与显示相关的,所以为它创建了一个名为 STFBaseRenderer
的新 renderer。这个新标记称为 STFBaseTag
,它声明 STFBaseRenderer
作为其关联的 renderer。不需要新的组件。
有了这些信息,通过继承 BaseTag
并覆盖 getRendererType
方法创建新的 STFBaseTag
,如下所示:
|
恭喜!经过这些相对较小的修改,您已经成功地集成了 Struts、Tiles 和 JSF,并保留了您以前在这些技术上所做的所有投资。本文演示了如何将 JSF 强大的前端能力、 Tiles 的内容格式编排优势以及 Struts 控制器层的灵活性结合在一个包中,使得创建一个 J2EE Web 应用程序成为一项更容易的任务。
padding-top: 0px; padding-right: 0px; padding-left: 0px; padding-bottom: 6px; clear: both; text-align: left; margin-top: 0px; margin-right: 0px; marg
评论