这是jsf 的分析系列第三篇，随着不断的深入，jsf的设计变得越来越清晰。当然，在目前的规范中，jsf还是很不完善的，这也就导致了为什么jsf还是不能成为目前的主流框架。先不去谈论这些弊端，还是先看看一下jsf具体是如何运作的。
对于jsf规范，个人觉得和其他框架相比，最大的区别，可能在于jsf划分了web 请求的生命周期。like ejb一样，web 请求也是有生命周期的。虽然，在其他的框架中，也可以看到相关的生命周期，但还是没有jsf划分的清晰。也许，这也是jsf的一大特色。
对于生命周期的执行，所有的操作都归结到Lifecycle这个接口。接口包括了两个主要的方法：
public abstract void execute(FacesContext context) throws FacesException;和
public abstract void render(FacesContext context) throws FacesException;
前者是用来执行各个生命周期的阶段，也就是除了render之外的其他五个阶段，而且是按照相应的顺序执行。而render，是执行最后一个阶段，展示页面。可能有人不太理解，为什么不把两个方法合并成一个方法，刚开始，我也是这么认为。既然已经定义了相应的Phase，何必要把最后的render过程分离出来。看了sun 的RI实现类，发现在render之前需要进行context.getResponseComplete()判断，可能规范中，认为render是必须要执行的阶段，其他的阶段可以跳过，所以分离了相应的方法,同时在执行前,为了避免重复输出,需要对render过程进行特殊的处理.
规范中定义了6个阶段，从下面的流程图中可以看到。
简单介绍一下每个阶段的工作：
RESTORE_VIEW：查找原有的view ，恢复原有的状态，如果没有，则调用ViewHandler.createView，如果为post操作，则按照顺序执行各个阶段。
否则执行RENDER_RESPONSE阶段。
APPLY_REQUEST_VALUES：读取客户端参数，处理各个组件的processDecodes方法，内部调用decode方法，由Renderer执行decode方法
PROCESS_VALIDATIONS：执行组件的processValidators方法，对于UIInput执行validate方法，用于绑定值，调用convert,和validate
UPDATE_MODEL_VALUES:执行组件的processUpdates方法，对于UIViewRoot，执行broadcastEvents和notifyPhaseListeners
所有的UIInput,执行updateModel方法。
INVOKE_APPLICATION：调用UIViewRoot.processApplication方法。这一过程主要读取相应的action配置，如果存在action，则调用action，也就是调用应用逻辑。在执行完相应的逻辑后，查询action是否返回值，如果有，由navigationHandler去读取下一个view id。
RENDER_RESPONSE：展示view，调用ViewHandler.renderView,展示view。
每个阶段定义定义的都比较清晰，有一点需要注意的是，在处理请求时，并不一定会执行每个阶段，可能其中会直接跳到最后的render response阶段。举例来说，如果validator时，存在错误信息，那么就会直接到render response阶段，而下一个阶段不会执行。
posted on 2007-05-04 15:44
布衣郎 阅读(3502)
评论(3) 编辑 收藏 所属分类:
web view技术