我的目在JSF和AJAX的整合。不管你选择什么版本的JSF，与AJAX的整合对于构建企业级应用程序来说是一个不错的选择。我会给大家展示这两种技术结合的方法，我特意增加了一些新内容——因为在这之前，已经有了JSF和AJAX的实际测试方法，但这种测试方法出现并不只局限于与JSF整合的AJAX应用，任何AJAX应用程序都可以使用．最后，我还会陈述一下如何评价JSF和AJAX的解决方案． 现在，我发现JSF与最初的2001年所处的情况惊人的相似——那个时就已经有许许多多的web框架，真可谓是百家争鸣，而JSF在其中脱颖而出，以绝对优势成为JCP标准．但现在，这种局面再次出现了．在过去的六年，我们始终紧跟时代的步伐，但仍然还有大量的web框架鏖战在我们周围，但是根据从采用JSF技术的网站数据以及供应商为之提供的工具和组件数量来看，JSF还是在不断增长且在市场上仍有一席之地，因此许多供应商也相继推出了JSF和AJAX整合方案．在今天下午2:30的小组讨论中，我和来自ICEsoft的Steve Maryka会一同出席，大家也许已经知道Steve已经推出一套相当漂亮的JSF和AJAX整合方案．届时我会以Sun代表身份出现，当然除Steve外，还有很多知名人士，我会将他们的姓名列在幻灯片上．但不管怎样，我只想给你们提供一些信息，以便当你看完这些不同的解决方案后，扪心自问：哪一个方案是最佳的？它有什么特性？这些特性可以满足我的企业要求吗？
“企业级”已经是一个被过度滥用的术语了．那么按照我自己的理解，企业级指的是健壮，可伸缩，易于测试以及被业界证明可用性(industry proven)等．它需要被开发人员证明切实可行！JSF满足上述要求，因为刚才我所讲的大量的站点和大量的供应商支持足以证明这一点．另一个关于“企业级”的说法是：易于使用，易于开发，当然也包括易于测试．TDD（测试驱动开发）我的确喜欢，当我在领导团队开发一个JSF实现时，我们所做的一切都采用了TDD，并且效果显著．当然，“企业级的工具”也需要同时能够满足开发人员的需求．这一切往往在职场上扮演重要角色：你会雇用什么样的人才？他们所掌握的技能能够胜任这个开发工具吗？现存的开发工具是否又能满足他们的要求呢？并且最后一点我要强调的是：良好的可扩展性观念．当你所遇到的问题越来越多时，你所依赖的解决方案也要不断的提供抽象来解决这些不断增长的问题，此时JSF作为一个基于组件和多个扩展的解决方案，支持抽象和组件化满足了可扩展性．这就是我所定义的“企业级”概念．
那么我所指的AJAX，也在这里告诉给大家吧：web应用程序通过使用异步机制与服务端进行交互，并且动态更新浏览器所显示页面的外观和行为．这么来定义AJAX我觉得还是有稍稍有点生硬．如果你与ICEsoft接触过，你会发现他们已经有了AJAX的“推”模式，使用了大量技术可以异步的将内容通过浏览器发送出去．大家熟知的Comet就是这种编程模式的一种实践，它在与AJAX整合时非常有用，不过今天我没有在幻灯片上提供任何关于它的信息，但是可以很明确地的说：Comet就是为与AJAX整合，当然也包括与JSF的整合．
好了，说完了的目的后，正式开始我们今天的议程吧．为什么JSF要与AJAX整合？为什么我会强调AJAX对于web应用程序来说是必须的？JSF和AJAX的整合方法有很多．其中JSF本身的设计和特性就使得它适合协同AJAX进行开发．下面是我们调查到的一些问题和解决方案．
一个解决这些问题的方案来自于Project Dynamic Faces（JSF的一个AJAX扩展）和MCP（Mozilla Control Program，使用JUnit或TestNG来自动测试web应用程序的一个包）．这是一个很早就有的解决方案，当时我还在www.mozilla.org工作时已经有些Alpha级的技术来自动测试AJAX程序．现在我手头上有一些关于它的demo。
所有的web应用程序必须经过下列过程．为确保万无一失(motherhood applepie：美国黑话或政治家惯用的说语)，你需要进行数据转换和数据验证，需要一种机制来指定页面流程(page flow)，需要整合数据库．当然，你也许还会用持久层技术，比直接就可用的JAP和Hiberante．你还需要alphabet soup，国际化，本地化，以及易于访问．而这说到的最后一点，自AJAX它诞生以来，就一直是开发人员的痛．AJAX的反对者们大声嚷嚷：“好啊，你别想向政府部门卖出任何AJAX应用程序，因为有Section 508法案．”的确，有大量的实事摆在了面前，但不管怎么样，web应用程序必须是易于访问的．即使当你在制作页面的时候，你也需要考虑到对多语言的支持，以及基于CSS的样式设计．同样，它还需要保证，不管在单元测试还是系统测试级别上都要求是可测试的．最后一点就是用户体验了，所有这一切来来回回最终还是从开发人员到测试人员然后再到达最终用户．
现在，各种不同整合JSF和AJAX的方法都是为了降低复杂度。我现在为这些解决方案亮起了红灯。（这些解决方案都）有很多的赞成和反对的声音，但亮起的红灯表明反对占了上风。那么我要说的第一个整合JSF的方式就是直接使用Naked AJAX（未经过任何封装的AJAX），你打算一切靠自己，什么都打算自己写! Frank Zammetti写了一本书，他发明了“Naked AJAX”这个术语，指的是你不使用任何AJAX框架，全部由自己亲自来完成。如果你这么做，你会深入的理解AJAX底层的技术，因此很可能你在职业上炙手可热并且这也一切也确实是你想要得到的话，那么我不得不说你太有才了。
你必须亲自处理所有的使用XMLHttpRequest的交互请求，这就要求你有扎实的JavaScript基本功，使用SetTimeout函数等以及一系列常人所不愿意使用的技术。到时候，你还不得不去解决跨浏览器之痛，而这种痛苦对于web开发人员来说已经持续多年，最后为了与它有一个了断，你还是陷入了开发自己框架的沼泽之中。
第二个解决方案显得更高级些，因为你使用了JavaScript框架。现在已经有大量可用的JS框架充斥在我们周围，比如Dojo,DWR,Prototype等，这些框架也是今天要讨论的内容。但使用这些JS框架的话，你仍然需要去为你的web应用程序编写代码，而且一旦在JSF中使用了某个JS框架（比如说Dojo）的话，你又要去编写那些侵入性代码了。
Struts组件编程必须限定在Action/ActionForm/JSP这三个框框中做文章，难度相对比较大，而Tapestry/JSF则没有太多这些技术框框限制，两者在组件编程方面更让编程者自由一些，方便一些，这也是组件型框架的优势吧。
Struts标签库
在Struts中，经常需要使用标签库来显示组件ActionForm中内容，这就涉及到一个结合的问题，标签库是别人写的，参考Struts的标签库用法，而组件是自己的，难度和麻烦就体现在这个结合点上。
JSF基本思路和Struts差不多，只不过换了不同标签库，也需要标签库+组件的结合思考，不过因为组件这里是通用组件，没有什么限制，所以这样比Struts要轻松一些。
Tapestry使用了组件库概念替代了标签库，没有标签库概念，这样就没有标签库和自己的组件需要结合的问题，都是组件的使用，组件中分Tapestry标准组件和自己定义的组件，这也是接触了Jsp体系的人学习Tapestry面临的一个思路转换。
具体以页面跳转为例子，页面跳转是靠链接 实现，链接是页面经常使用的元素。
Struts提供的html:link在频繁使用就特别不方便，尤其在传递多个参数时：其中html:link的page值，是跳转对方页面或 Action的path，这个path一般需要到struts-config.xml查找Action的相应path,一旦配置文件path值修改，涉及到这个所有相关页面都要修改。
JSF将链接概念划分两个方面：导航性质和事件激活，在导航方面还是需要到配置faces-config查询Navigation的from-outcome的值。
由于Tapestry没有标签库概念，只有组件或页面两个概念，因此，链接跳转目标要么是组件，要么是页面，简洁简单，它没有多余的path概念，就是组件名，也就是对象名称，组件名称和path名称合二为一。
总结
JSF在很大程度上类似Struts，而不是类似Tapestry，可以说是一种Struts 2.0，都是采取标签库+组件的形式，只是JSF的组件概念没有象Struts那样必须继承ActionForm的限制；JSF在事件粒度上要细腻，不象 Struts那样，一个表单一个事件，JSF可以细化到表单中的每个字段上。
JSF只有在组件和事件机制这个概念上类似Tapestry，但是不似Tapestry那样是一个完全组件的框架，所以，如果你做一个对页面要求灵活度相当高的系统，选用Tapestry是第一考虑。
Struts/JSF则适合在一般的数据页面录入的系统中，对于Struts和JSF的选用，我目前个人观点是：如果你是一个新的系统，可以直接从JSF开始；如果你已经使用Struts，不必转换，如果需要切换，可以将JSF和Tapestry一起考虑。
另外，JSF/Tapestry不只是支持Html，也支持多种客户端语言如WML或XUI等。
这三者之间关系：如果说Struts是左派；那Tapestry则是右派；而JSF则是中间派，中庸主义是SUN联盟的一贯策略。
当然，你也可以发表你在实践中这三者任何一个的使用感受，以使得后来者有一个比较。
【编辑推荐】
