与很多流行的观点不同，我们无需了解技术工作原理的所有细节，就可以编写 JSF 应用程序。您只需要给自己设置一个项目，并从头到尾不断修修补补，这样就可以学习到大量的知识。另一方面，理解必要的基础知识可以使您的开发工作更加有效 —— 而且会节省很多时间。
在本系列 怀疑论者的 JSF 的第 2 篇文章中，我们将逐一介绍一下 JSF 请求处理生命周期的 5 个阶段。我们将介绍在每个阶段中会发生什么，以及这些阶段是如何相互连接在一起的，然后使用一个示例程序来展示实际的生命周期。我们还将向您介绍如何在 JSF 开发中采用 Struts Tiles，以及如何组合使用 JSF 和 JavaScript 技术进行即时事件的处理。
正如上一篇文章中介绍的一样，示例程序的默认编译环境是 Maven。您可以通过点击页面顶部或底部的 Code 图标下载源代码。为了简单性起见，您会发现与上一篇文章中一样的示例设置。
JSF应用程序的生命周期：概述
JSF 程序生命周期的 5 个阶段如下（注意每个阶段的事件处理）：
1. 恢复视图
2. 应用请求的值；处理验证
3. 更新模型值；处理事件
4. 调用程序；处理事件
5. 进行响应；处理事件
这 5 个阶段显示了 JSF 通常处理 GUI 的顺序。虽然这个清单列出了每个阶段中事件处理的可能执行顺序，但是 JSF生命周期很难是固定一成不变的。您可以通过忽略某个阶段或合并整个生命周期从而对执行顺序进行修改。例如，如果一个无效的请求值被拷贝到一个组件中，那么当前的视图就会重新显示，而有些阶段就可能不会执行。在这种情况中，您可以执行一个 FacesContext.responseComplete 方法调用，将用户重定向到一个不同的页面上，然后使用请求分发器（从 FacesContext 中的请求对象中获得）将其转发到一个适当的 Web 资源上。另外，您可以调用 FacesContext.renderResponse 重新显示原来的视图。（详细信息请参看下面的示例程序。）
关键是让生命周期构成您的开发项目，而不完全依赖于生命周期。在需要时，您可以修改生命周期，而不用担心破坏您的程序。在大部分情况中，您会发现 JSF生命周期是值得遵守的，因为它的逻辑非常好。表单必须在任何应用程序逻辑执行之前进行验证，并且在进行验证之前，必须对域中的数据进行转换。遵守生命周期的规定，可以让您更自由地考虑有关验证和转换的问题，而不是请求处理本身的阶段。有一点非常重要：其他 Web 框架也都具有类似的生命周期；它们只不过是没有很好地进行宣传。
专注
有些使用 JSF 的开发者可能从来都不会编写一个组件，也不会对框架进行任何扩展；而另外一些人则专注于这种任务的开发。尽管 JSF生命周期与大部分那其他项目都是相同的，但是根据在项目中的角色您可以采用不同的阶段。如果您更专注于通用的应用程序开发，就可能会关注请求处理生命周期的中间阶段：
◆应用请求值
◆更新模型值
◆调用程序
如果您专注于 JSF 组件的开发，就可能会关注于整个生命周期中的第一个阶段和最后一个阶段：
◆恢复视图
◆进行响应
在接下来的几节中，我们将遍历 JSF 请求处理生命周期的每个步骤，包括事件处理和验证。了解了每个步骤的基本知识之后，我们将简要介绍一个示例程序，它可以展示这些步骤如何一起使用。在开始之前，首先来看一下图 1，这是一个有关 JSF生命周期的图。
阶段 1：恢复视图
在 JSF生命周期的第一个阶段 ——恢复视图 —— 中，会有一个来自 FacesServlet 控制器的请求。控制器会对请求进行考查，并提取出视图的 ID，这是由 JSP 页面的名字来确定的。
JSF 框架控制器使用这个视图 ID 来为当前的视图查找组件。如果这个视图尚未存在，那么 JSF 控制器就会创建它。如果这个视图早已存在，那么 JSF 控制器就会使用它。这个视图包含了所有的 GUI 组件。
生命周期的这个阶段表示为三个视图实例：新视图、原始视图和后视图，每个视图的处理方式都不相同。在 新视图 的情况中，JSF 会构建 Faces 页面的视图，并将事件处理程序和验证程序绑定到组件上。这个视图被保存在一个 FacesContext 对象中。
FacesContext 对象包含了 JSF 用来管理当前会话中当前请求的 GUI 组件状态所需要的所有状态信息。FacesContext 将视图保存在自己的 viewRoot 属性中；viewRoot 包含了当前视图 ID 的所有 JSF 组件。
在 原始视图 的情况中（第一次加载的是一个页面），JSF 会创建一个空视图。这个空视图会在用户事件产生时进行填充。JSF 可以直接从原始视图过渡到进行响应的阶段。
在 后视图（postback） 的情况中（用户返回之前访问过的页面），包含页面的视图早已经存在了，因此只需要进行恢复就可以了。在这种情况中，JSF 就使用现有视图的状态信息来重构状态。后视图的下一个阶段是应用请求值。
阶段 2：应用请求值
应用请求值 阶段的目的是让每个组件检索自己当前的状态信息。这些组件必须首先通过 FacesContext 对象进行检索或创建（使用其值）。虽然组件值也可以从 cookie 或头文件中进行检索，但是它们通常是通过请求参数进行检索的。
如果一个组件的即时事件处理属性 没有 设置为 true，那么就会对这些值进行转换。因此，如果 域 被绑定到一个 Integer 属性上，那么该值就会被转换为一个 Integer 类型。如果值的转换失败了，那么就会生成一个错误消息，并在 FacesContext 中进行排队，在产生响应的阶段会显示其中的消息，同时还会显示所有的验证错误。
如果一个组件的即时事件处理属性 的确 被设置为 true，那么这些值就会被转换为适当的类型，并进行有效性验证。然后转换后的值会被保存到组件中。如果值转换或值的有效性验证失败了，就会生成一个错误消息，并在 FacesContext 中进行排队，在产生响应的阶段会显示其中的消息，同时还会显示所有的验证错误。
处理验证
生命周期中的第一个事件处理发生在应用请求值阶段之后。在这个阶段中，每个组件都有一些值需要根据应用程序的验证规则进行有效性验证。这些验证规则可以是预先进行定义的（JSF 中提供的），也可以由开发者进行定义。用户所输入的值会与这些验证规则进行比较。如果说输入的值无效，就会向 FacesContext 中添加一个错误消息，并且该组件会被表示为无效的。如果一个组件被表示为无效的，那么 JSF 就会转到产生响应的阶段，在这个阶段中会显示当前的视图，以及验证错误消息。如果没有有效性验证错误，那么 JSF 就会转到更新模型值的阶段。
阶段 3：更新模型值
JSF 应用程序生命周期中的第三个阶段 ——更新模型值 —— 负责更新服务器端模型的实际值，通常来讲，这都是通过更新后台 bean（称为管理 bean）的属性实现的。只有那些与组件值绑定在一起的 bean 属性才会被更新。注意这个阶段发生在有效性验证之后，因此可以确保拷贝到 bean 属性的值都是有效的（至少在表单域一级都是有效的；在业务规则一级仍可能无效）。
阶段 4：调用程序
在生命周期的第四个阶段 ——调用程序 —— 中，JSF 控制程序会调用程序来处理 表单 的提交操作。组件值已经经过了类型转换和有效性验证，并被应用到模型对象中了，因此您现在可以使用它们来执行应用程序的业务逻辑了。
在这个阶段，您还可以为一个给定的序列或很多可能的序列指定后面的逻辑视图，这可以通过为一次成功的表单提交定义一个特定的结果并返回这个结果来实现。例如：在成功输出时，将用户重定向到下一页中。要让这种导航工作能够起作用，您需要在 faces-config.xml 文件中创建一个到 成功输出 的映射作为一条导航规则。一旦导航发生之后，您就转换到生命周期的最后一个阶段了。
阶段 5：进行响应
在生命周期的第五个阶段 ——进行响应 —— 中，您可以在视图中显示当前状态中的所有组件。
【编辑推荐】
