了解jsf的架构 一

经过一段时间的学习，对jsf的认识也逐渐清晰。总结了一下jsf和structs的区别，首先在于分离了请求的处理。使用事件处理机制来代替原有的request分发。其次在页面的展示上，采用组件的概念，而不是到处散落的html标记。再有，jsf对于请求的生命周期重新进行了划分，对于每个阶段都可以派遣事件，这使得整个请求的处理比较的清晰。最后，jsf对于页面的流转使用Navigation系统来处理，这一点感觉和structs还是比较类似的，只是换了一个概念。

从jsf的规范来看，jsf整个架构还是比较清晰，各个层次分的也挺明显。从总体上看，规范主要划分了application,context,lifecycle,render,component,validator,event,el几个部分，当然少不了主要的入口Servlet。有一点不太明白，大多数的类都是抽象类而不是接口，可能是为了规定层次吧，不允许多层次继承。下面简单以下介绍各个包的功能：

application:从定义上就可以看出来，这是应用级的。中间包括了Application主类，这是主要的程序入口，规范中最具有重量级的类，也是用来连接各个模块的。jsf规范使用工厂的模式,来创建相应的实现类.当然如果需要Application的实现，需要从ApplicationFactory中取得。除了Application类，其中还包括了ViewHandler，这个主要负责View的Renderer调配工作。而许多jsf实现框架，如果想定义自己的行为，一般上都会使用自身的ViewHandler，如facelets。NavigationHandler的工作，不用说已经很明显，就是用来负责页面之间的导航。包中，还包括了view状态管理类--StateManager,主要用于恢复view，以及保存view。目前一般使用Session来保存相应的view，当然也可以使用客户端来保存。其实，对于view状态的保存，非议还是挺多的，而且问题也比较多。

context：包括了主要的上下文环境类，如FacesContext和ExternalContext，前者是jsf的主要Context类，包括对message的管理，Application的取得，以及ResponseWrite的引用。后者主要类似于作为外部环境的引用类，如ServletContext和PortletContext.ResponseWriter,主要的服务端Writer，用于输出相应的html,xml内容，所有的Renderer都需要引用此类

lifecycle:这是jsf最大的特色，划分了请求的相应的处理阶段。规范中，只有两个类Lifecycle和LifecycleFactory。Lifecycle管理整个jsf请求的生命周期。通过指定的顺序执行相应的阶段。

webapp:定义了主要的Servlet，FacesServlet，主要的请求分发类，用于转换相应得faces为实际的资源。在规范中，Servlet并不是主要的初始化类，jsf的初始化工作主要由具体的实现完成。在RI实现中，基本上由ConfigureListener完成初始化工作。而Servlet的任务只是简单的传递请求参数而已，以及调用相应的Lifecycle而已。

这里主要讲了jsf的整体架构包，下一篇主要分析一下jsf相关组件的包。