JavaServer Faces对决Tapestry

JavaServer Faces对决Tapestry
面对面的对比
作者：Phil Zoio 发布于The Server Side
原链接：
http://www.theserverside.com/articles/article.tss?l=JSFTapestry
本人翻译了其中一小部分，如果侵犯版权请通知我，谢谢。
很有趣，里面提出是一种实现（Hibernate、Spring）更能推动产业呢？还是一个标准（JSR）呢？很难回答。
Tapestry的分离方式非常优雅，后来被很多其它实现所参照，但Tapestry是做的最好的。你甚至可以用Dreamweaver来写模版，这对于那种美工不懂JSP、JAVA的团队非常有效，静态的预览也很容易。
而JSF对于组件化的推动是非常有效的，派生了很多好的页面组件，这是非常好的重用思想。比如IBM就把JSF和SDO结合，产生的东西绝对令人印象深刻（在加上Ajax实现）。
本文开头说明Struts作为一个MVC实现已经有点越发老迈了，日落西山是早晚的事。而新一代的MVC，象Web Work那些都是更佳的实践。不过JSF和Tapestry提出的上面两个优雅的解决对表现层更加友好，所以要对比一下。
文中对比了Tepestry 3.0.3和JSF 1.1。大家注意Tapestry 4已经进入beta阶段，而且变化是翻天覆地的，里面也提及了一些。
文章很长，看起来还是有点累的。不过比起学习两个技术，看看这种文章对你学习之前是个很好的指导。
标准1：页面开发
Tapestry的可融入标准HTML的能力区别于其它框架，是最有价值的功能。
标准2：Java编程模型
JSF为创建程序类提供了直观且具有弹性的编程模型，相对于Tapestry中一些奇怪的设置要自由得多。
标准3：请求（Request）处理生命周期
JSF更容易访问，而Tapestry的方式更适合于复杂的需求，它允许人们为需求中的单独操作定制生命周期。
标准4：导航
两个框架都有怪癖；作者偏向于Tapestry的基于编码的方式来导航。
标准5：事件处理
JSF受益于值变化事件监听器。对于Tapestry，当事件处理逻辑是逐个页面设定的，这个生命周期事件处理模型会更适合。而JSF更适合于对整个系统整体设定的生命周期事件处理。
标准6：组件状态管理
Tapestry有效的组件状态管理机制，使人们对它的能力和适用范围有足够的信心。对于不需要高性能的程序，重绕（rewind，Tepestry的一个毛病）问题是你愿意摆脱的。
标准7：标准组件
Tapestry提供了领先的标准组件集，而JSF得益于大量的第三方组件。
标准8：组件开发
在Tepestry中进行自定义组件开发相对容易于JSF。
标准9：验证和转换
JSF在概念上占有优势。但是Tapestry在客户端验证支持上挽回了弱势，它具有更加的错误管理机制，和更多的系统外验证的实现。
标准10：国际化
Tepestry的优势在于紧凑的格式，而且它的国际化页面可以进行预览。
标准11：可测试性
相对少的框架依赖使在JSF中进行受控bean单元测试比Tepestry页面类单元测试更加容易。
标准12：开发者获得的效率提升
由于工具的愈发面面俱到和易于使用，JSF的开发效率可以得到提升。对于那些喜欢以代码为中心的开发者，Tapestry可能会更有效率。
标准13：易于学习
JSF框架对于一般开发者更容易上手，虽然Tapestry中的模版创建很容易上手（但是它的学习曲线更难，资料也不全，且正在从3升级到4，有翻天覆地的变化）。
标准14：业界支持
JSF是个工业标准，所以受到广泛的业界支持，他更容易吸引IT经理人和开发者。（里面说JSF会慢慢好找工作，当然Struts还是最大需求。而Tapestry估计不会作为招聘要求的技能。）
标准15：可扩展性
JSF提供了比Tapestry 3更加优雅的扩展机制。Tapestry 4会很大程度上改进框架的这种能力。