Ajax为什么这样红?有人说，是因为起了个好听易记的名字(比如荷兰著名的Ajax球队，即阿贾克斯);也有人说，是因为Google全新的Ajax应用产品给人们带来的超酷体验(比如伟大的Google Maps、GMail等)。确实如此，Ajax能够如此流行的最主要原因就是它带来了更好的用户体验，改变了人们对传统Web应用的不佳印象。

　　然而，即使Ajax的狂热Fans也不得不承认的是，从技术层面上来说，Ajax并没有带来什么新鲜的东西。它本质上是一种新瓶装旧酒的技术，好处是通过Java Script与DHTML提供了一种异步编程模型，从而使Web应用给客户带来了更好的人机体验。正如我在去年引起大家争论的拙文《Ajax，只是一种过渡技术》中表述的：Ajax解决问题的层面较低。或者说，它解决问题的方法与手段，很难形成一种可高度抽象的框架级解决方案。并且，正是因为Ajax基于Java Script，因此不可避免地带来了Java Script的诸多缺点，譬如：

　　跨浏览器是一场噩梦

　　对搜索引擎的支持不好

　　干掉了Back、History等按钮(尽管我并不认为Back、History是什么好东西)

　　开发与维护成本过高

　　要Java, 不要Java Script

　　We Love Java, Not Java Script。套用毛泽东的惯用句式就是：“要Java, 不要Java Script”。相信很多读者看完这个标题也许会不以为然，但这句话却代表了许多J2EE开发人员的心声。

　　众多Java工程师都对Java有一种近乎偏执的喜爱，他们热爱Java的简洁与优雅。但一旦让他们去进行Java Script的开发，却往往会不知所措：过度灵活的语法，无法通过编译器进行语法校验，缺乏良好的调试工具等等这些，都会让人们对Java Script畏手畏脚，更遑论Ajax的开发。

　　一句话，Java社区需要Ajax，需要它来提升基于JavaEE的Web应用的人机体验;但是，人们并不喜欢Ajax目前的开发模式。无疑，我们需要一种新的解决方案。

　　谁来拯救JavaEE的Ajax?

　　我给出的答案是JSF。目前，关于JSF的一种流行说法是“悲剧人生：Sun让JSF光着身子降临到Java Web世界”。然而，我的看法却是：作为一种革命性的服务器端组件技术，JSF犹如早晨八九点钟的太阳，前途不可限量。

　　让事实说话，我们先来看看JSF请求/响应过程的标准生命周期：

　　图1：JSF的生命周期

　　通过上图可以观察到，任何一个JSF“Faces Request” 请求，经过Restore View、Apply Request Values、Process Validations、Update Models、Invoke Application等阶段以后，产生了一个 “Render Response” 返回给客户端。那么，常规JSF引擎是如何实现上述过程的呢?

　　图2：常规JSF引擎的请求与响应过程

　　回顾一下常规JSF引擎针对请求与响应的过程：首先，客户端请求某个资源，产生一个Faces Request;服务器端接收到此请求以后，经过一系列后台处理，产生一个Faces Response。我们注意到：响应的Content-Type是text/html，而产生的内容主体是一段HTML文本;浏览器在接收到HTML文本以后，进行整个页面的渲染与刷新。

　　无需写Ajax代码的Ajax Enabled应用

　　我用自己开发的JSF引擎，这样处理上述过程(详见参考资料www.OperaMasks.org )，如下图所示：

　　图3：OperaMasks JSF实现的请求与响应过程

　　首先可以观察到，Faces Request的发出是基于“x-requested-by: XML Http Request”，也就是说，这是一个Ajax请求，而该请求在到达服务器端以后，服务器端所产生的Faces Response同常规Faces Response相比也发生了变化：Content-Type不再是text/html，变成了text/javascript;并且，响应的主体也不再是html文本，而是一堆script脚本。浏览器在接收到响应以后，再也不需要进行整个页面的渲染与刷新，而只仅仅需要执行这段脚本内容，将页面的控件进行更新即可。

　　显而易见，通过上述JSF技术，我们获得了：

　　基于Ajax的请求、应答、及页面控件的更新

　　数据传输量明显减少

　　避免整个页面的刷新，更好的用户体验

　　系统保持敏捷、高效

　　换言之：任何标准JSF应用，只需将其在OperaMasks JSF引擎上运行，就可以达到这样的效果。我们并没有写任何一行Ajax的代码，但是，我们的应用却是自然而然的Ajax Enabled的应用。大道至简，大象无形。

　　奥妙所在：JSF的Render机制

　　为什么可以这样?

　　JSF组件只是特定状态和行为的载体，而组件以什么形式去和用户交互，是完全可定制的、独立于该特定的表现语言，可以是HTML、WML或者其他形式;具体是什么，可以通过指定JSF组件的Render Kit来实现，而每一种Render Kit，对应于组件作者写的同一风格和形式的一系列Render。

　　比如，如果想在网页中实现图表功能(Chart)，MSIE有VML，Gecko和Opera有SVG;而在服务器端只需要简单地判断一下浏览器类型，就可以选择一个Render Kit，生成不同的客户端表现来完成相同功能――这是用常规JSP技术很难完成的任务。

　　通俗的说，JSF组件可以翻译成任何你想要的形式。So，JSF框架比现有其它开源框架具有更强的生命力。上文所述的OperaMasks JSF，其容器级别Ajax实现，正是灵活应用Render Kit的具体案例。

　　从容器级别对Ajax予以支持的JSF引擎

　　我们提出的JSF是直接由JSF容器来处理Ajax请求的，它会根据请求类型来判断这是一个正常HTTP请求还是一个 Ajax请求：如果是常规HTTP请求就运行JSP页面，生成页面文档(特定的，对于Ajax Render kit，要加入一些Ajax基础JavaScript代码);如果是Ajax请求，服务器对请求参数正常解码，并执行JSF中除页面输出阶段以外的所有其他阶段，生成一个JSF组件树。

　　一直到这一步为止，处理方式与对普通HTTP请求的处理完全一致，唯一不同的是：在随后Render Response阶段，容器除了调用组件作者写的Ajax功能 Renderer以外，更重要的是在生成响应页面时，会过滤掉一切不会变化的静态内容――也就是说，静态内容不会生成到响应页面中去，而对每一个动态内容则会生成一个相应JavaScript代码(可以更进一步优化为只有变化了的动态内容才处理)。这样，传给客户的Ajax应答实际上是由这样一些JavaScript语句构成。在Ajax响应返回到客户端时，就可以自动由Ajax回调函数执行这些JavaScript语句，完成对页面即时的、局部的更改，而不需要刷新整个页面。依赖JSF组件的具体功能，甚至可以改变页面的外观。而整个Ajax机制由JSF引擎提供，对用户完全透明。

　　实际上，在JSF规范中JSF页面输出阶段所采用的Render Kit是可替换的，默认的HTML_BASIC Render Kit输出的是标准HTML语法，不包含任何Java Script代码。我们提出的JSF引擎实现了一个 Ajax Render Kit，可以在HTML文档中嵌入Java Script代码来实现Ajax特性，而替换Render Kit只需要修改配置文件即可。

　　简单地说，这种JSF引擎为每个标准组件都实现了相应的Ajax Render， 比如对UICommand组件，其Ajax Render会在onclick事件中加入JavaScript的Ajax提交代码，向服务器提交Ajax请求。通过这种方式，任何一个包含标准JSF组件的Web应用，都可以通过只更改Render Kit配置为Ajax来实现Web应用Ajax化。而对于第三方的组件，可能本身并不支持 Ajax，但使用一个名为的标签，就可以立即将这个第三方组件转换成Ajax Enabled。

　　例如，Apache myfaces的Tomahawk项目提供了一个Tree组件，这个组件本身并不支持Ajax，每当按下一个Tree结点都将重新刷新整个页面。使用标签后，则只刷新Tree部分，而不刷新页面的其他部分。当然更好的方式是，提供一个本身就支持Ajax的Tree组件，以减少冗余数据的传递。关于标签的原理，有兴趣的读者可以参考OperaMasks JSF的源码(详见参考资料)，这里就不再一一赘述了。

　　综上，JavaEE 需要Ajax，但并不需要传统的Ajax开发模式。通过我们提出的OperaMasks JSF技术，我们不再需要知道什么是Ajax，而我们的应用却是自然而然的Ajax Enabled应用。