JSF组件生命周期的讨论

1.       JSF生命周期

下面我们来看看JSF组件的生命周期，JSF组件的生命周期正常的话是6个阶段。这六个阶段是 JSF 处理表单 GUI 的一般次序。这个列表按照每个阶段可能的执行次序和事件处理进行排列，但是 JSF 生命周期并不是固定的。可以改变执行的次序，跳过某些阶段或完全脱离生命周期。例如，如果一个无效的请求值被复制到组件，那么会重新显示当前视图，并可能不执行某些阶段。还可以选择完全脱离 JSF，比如将处理委托给一个 servlet 或另一个应用程序框架比如ajax4jsf（他就是通过一个过滤器，让JSF组件生活在此AJAX框架之下）。在这种情况下，可以执行一个FacesContext.responseComplete ()方法调用，将用户重定向到另一个页面或 Web 资源，然后使用请求调度器（从 FacesContext 中的请求对象获得）转发到适当的 Web 资源。也可以调用 FacesContext.renderResponse 来重新显示原来的视图。 最重要的是，在利用生命周期组织您的开发工作的同时不会受其束缚。在需要时可以修改默认的生命周期，而不必担心破坏应用程序。在大多数情况下，您会发现采用 JSF 的生命周期是值得的，因为它非常符合逻辑。这也是为什么JSF比其他web框架标准更注重生命周期的概念了！！！

 比较清楚的如下

 

阶段 1：恢复视图

在 JSF 生命周期的第一个阶段 — 恢复视图 中，通过 FacesServlet servlet 发来一个请求。这个 servlet 检查这个请求并提取出视图 ID（视图 ID 由 JSP 页面的名称决定）。 JSF 框架控制器使用这个视图 ID 为当前视图寻找组件。如果这个视图还不存在，JSF 控制器就创建它,然后调用get方法（返回一个null），然后调用set方法（此时后台bing的组件将会被赋上值），然后进入渲染阶段——第6阶段。如果视图已经存在，JSF控制器就使用它，此时会调用组件对应的set方法进行恢复视图（会将上一次的值传入），而get方法此时不会调用，视图包含所有GUI组件。生命周期的这个阶段有三种视图实例：新视图、初始视图和postback，每种视图的处理方法各不相同。对于新视图，JSF 构建一个Faces页面的视图，并将事件处理函数和检验器连接到组件，视图保存在一个FacesContext对象中，FacesContext存储状态信息，JSF需要使用这些信息为当前请求管理GUI组件的状态。FacesContext将视图存储在它的 viewRoot属性中；viewRoot包含与当前视图ID对应的所有JSF组件。对于初始视图（第一次装载页面），JSF 创建一个空视图。在处理 JSP 页面时，填充这个空视图。填充初始视图之后，JSF 直接进入显示响应阶段。对于postback（用户返回到以前访问过的一个页面），与页面对应的视图已经存在，所以只需恢复它。在这种情况下，JSF 使用现有视图的状态信息重新构造它的状态。

 

阶段 2：应用请求值

应用请求值阶段的目标是获取每个组件的当前状态。首先，必须从FacesContext对象获取或创建组件，然后获取它们的值。组件值常常取自请求参数，但是也可以取自 cookie或请求头。对于许多组件，来自请求参数的值存储在组件的submittedValue 中。如果组件的直接事件处理属性是true，那么值被转换为正确的类型并被检验（在下一阶段中进一步进行转换）。然后，将转换后的值存储在组件中。如果值转换或值检验失败，那么生成一个错误消息并放在FacesContext中，在显示响应阶段，这个错误消息与任何其他检验错误一起显示。

 

阶段 3：处理检验

转换和检验一般发生在处理检验阶段。组件转换并存储它的submittedValue。例如，如果字段绑定到一个Integer属性，那么值就转换为一个Integer。如果值转换失败，那么生成一个错误消息并放在FacesContext中，在显示响应阶段，这个错误消息与任何其他检验错误一起显示。在应用请求值阶段之后，发生生命周期的第一次事件处理。在这个阶段，根据应用程序的检验规则检验每个组件的值。检验规则可以是预定义的（JSF 附带的），也可以由开发人员定义。将用户输入的值与检验规则进行对比。如果输入的值是无效的，就将一个错误消息添加到 FacesContext 中，并将组件标为无效。如果一个组件被标为无效，JSF 就跳过其他阶段，进入显示响应阶段，就会显示当前的视图和检验错误消息。如果没有发生检验错误，JSF 就进入更新模型值阶段。

 

阶段 4：更新模型值

JSF 应用程序生命周期的第四个阶段 — 更新模型值 — 通过更新托管 bean 的属性，更新服务器端模型的实际值。只有绑定到一个组件的值的 bean 属性被更新。注意，这个阶段在检验之后发生，所以可以确信复制到 bean 属性的值是有效的（至少在表单字段级上有效；它们在业务规则级上仍然可能是无效的）。在调用应用托管Bean的业务方法之前，对其属性进行set。

 

阶段 5：调用应用程序

在生命周期的第五个阶段 — 调用应用程序 — JSF 控制器调用应用程序来处理表单提交。组件值已经经过转换、检验并应用于模型对象，所以现在可以使用它们执行应用程序的业务逻辑。在这个阶段，调用您的动作处理方法，比如这个示例应用程序的 ContactController中的persist()方法和read()方法。在这个阶段，还为一个给定的序列或可能的多个序列指定下一个逻辑视图。对于成功的表单提交，可以定义特定的结果并返回这个结果。例如，在得到成功的结果时，将用户转移到下一个页面。为了让这个导航操作起作用，必须在 faces-config.xml文件中以导航规则的形式为成功的结果创建一个映射。发生导航之后，就进入生命周期的最后一个阶段。JSF获得从动作方法返回的对象并调用它的toString()方法。然后使用这个值作为导航规则的结果。（在第1部分中讨论过导航规则的配置。）

 

阶段 6：显示响应

在生命周期的第六个阶段 — 显示响应，显示视图和它的所有组件，这些组件都处于当前状态。如果对组件的属性进行的绑定，此时将会调用get方法。

在博客http://mingj.iteye.com/blog/478987中，博主对生命周期看得比较透彻，推理、猜想、调试也十分到位，建议大家看看。

开发人员可以自己写一个实现了javax.faces.event.PhaseListener接口的类，利用这个类可以监听到JSF组件的生命周期阶段。这个用于监控、调试、排错很有帮助。先看类代码

package lifeEvent;

import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;

public class JSFLifeEventListener implements PhaseListener {

	@Override
	public void afterPhase(PhaseEvent phaseEvent) {
		System.out.println("监听到了");
		PhaseId phaseId = phaseEvent.getPhaseId();
		System.out.println(phaseId);
		Object sourceObject = phaseEvent.getSource();
		System.out.println(sourceObject.getClass().getName());
	}

	@Override
	public void beforePhase(PhaseEvent arg0) {
		// TODO Auto-generated method stub

	}

	@Override
	public PhaseId getPhaseId() {
		return PhaseId.ANY_PHASE;
	}

}

 afterPhase()是到监视的生命周期的之后要执行的方法，beforePhase()就是在组件到此生命阶段之前要执行的方法，getPhaseId就是设置此监听器关心的生命周期阶段。此处是设置为全部监听、全部都有兴趣！之后在JSF配置文件加入如下片段

<lifecycle>
	<phase-listener>lifeEvent.JSFLifeEventListener</phase-listener>
</lifecycle>

 告诉JSF控制器启动哪个生命阶段监听器。