五、 JSF和Tapestry的全面比较
为了对JSF和Tapestry进行全面的比较，让读者了解这两种框架各自的优缺点，以便于在自己的项目中，根据实际情况，选择合适的框架，对它们两者进行比较，总结了如下表分析比较。
|
|
JSF
|
Tapestry
|
|
设计架构
|
跳转模型：Front Controller+组件化编程。
|
页面模型：Page Controller+组件化编程。
|
|
编程模型
|
业务逻辑：POJO的编程风格；页面逻辑：主要是JSP，也可以用HTML风格。
|
业务逻辑：Taperstry4需要继承基类；但Taperstry5就是POJO风格；
页面逻辑：普通的HTML。
|
|
请求处理
|
由官方定义的六个步骤组成；
|
取决于Engine Service。
|
|
导航
|
通过faces-config.xml配置文件完成。
|
URL是全局的，没有额外的配置文件；
除非显式跳转，所以行为都在本Page上。
而跳转分两种：
1. DirectLink写在页面上
2. 在代码逻辑中定义页面跳转逻辑。
|
|
事件处理
|
页面定义事件发起；两种方式参数传递方式：一种分离传递；另一种通过FacesContext。
|
页面定义事件发起；直接赋予参数，没有参数个数限制；除此外还有内置的生命周期相关的event
|
|
组件状态
|
没有状态维护机制，每次request都从建组件。
|
提供组件状态的维护机制。
|
|
组件开发
|
基于JSP Tag的开发方式。
|
开发方式类似Page, 逻辑代码和页面分离，页面输出使用HTML。
|
|
视图
|
主要是JSP，也可以用HTML风格。
|
HTML
|
|
验证及转换
|
提供了多种方式支持，但客户端验证支持不好，同时在form一级的支持不好，通常需要项目自己定制。
|
同样提供多种方式支持；此外提供客户端的Validation；天然地支持form一级支持。
|
|
I18N
|
较好的支持。
|
很好的支持，额外提供预览功能。
|
|
可测试性
|
测试支持简单容易。
|
Tapestry4的测试不容易，不过Tapestry5的测试可以很简单。
|
|
扩展性
|
良好
|
良好
|
|
行业支持
|
JSF业界标准，业内厂商支持会比较多，不过未必不会出现EJB2的结局。
|
应用范围小于Struts，之前的版本学习曲线太高。
|
|
迁移性
|
从Struts迁移不难；
|
从Struts或者JSP迁移难度较大些。
|
六、 结论
JSF是一个强大的且可扩展的框架，无疑它将会是很成功的。尽管它目前还有不少的缺陷。它致力于解决JSP模板问题的方向是正确的，但可能不是最好的方法。笔者认为，能提供丰富的组件选择，特别是像Tapestry一样基于属性模型的设计，也许将会更加的适合JSF未来的方向。同时，降低组件开发的难度，也应将是JSF努力的方向之一，可以将模板机制引入组件开发模型。而这方面，Facelets无疑是最成功的。
JSF只有在组件和事件机制这个概念上类似Tapestry，但不是Tapestry 那样是一个完全组件的框架，所以，如果读者做一个对页面要求灵活度相当高的系统，选用Tapestry是第一考虑。JSF 则适合在一般的数据页面录入的系统中,对一个新的系统，可以直接从JSF开始；如果需要切换，可以将JSF和Tapestry一起考虑。另外，JSF/Tapestry不只是支持HTML，也支持多种客户端语言如WML或XUI等。这二者之间关系：如果说Tapestry比较极端点，那么JSF则比较中庸一点，中庸主义是Sun联盟的一贯策略。
总的来说，J2EE Web 框架目前处在一种群雄逐鹿的状态，没有一个绝对的领导者。Struts是最流行的，但是它的主架构师也是主要的开发者已经抛弃了它。被称为Struts取代者的JSF目前还没有获得足够的影响力。而同时，其他的框架如Tapestry正在慢慢开始流行。
