这是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个阶段,从下面的流程图中可以看到。
![](https://i-blog.csdnimg.cn/blog_migrate/e3382e0ceaa1fc830c80b542a53c7434.gif)
简单介绍一下每个阶段的工作:
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阶段,而下一个阶段不会执行。
对于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个阶段,从下面的流程图中可以看到。
![](https://i-blog.csdnimg.cn/blog_migrate/e3382e0ceaa1fc830c80b542a53c7434.gif)
简单介绍一下每个阶段的工作:
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阶段,而下一个阶段不会执行。