经典文萃：过渡技术的Ajax及ApusicJSF

文章作者 100test 发表时间 2007:09:06 12:32:44
来源 100Test.Com百考试题网

　　现在炒得正热的Ajax其实是一种新瓶装旧酒的过渡技术，相信未来一到两年之内将被新的技术所代替，它解决问题的方法与手段很难形成一种可高度抽象的框架级解决方案，而JSF则是一种可扩展的框架级解决方案。在J2EE下一代规范Java EE 5.0中，JSF被放到了一个非常重要的地位，J2EE社区试图通过JSF来统一Web应用的开发模式与方法。作为JCP组织成员的金蝶中间件，即将推出中国人作出的Apusic JSF…

　　1.前言

　　在J2EE下一代规范Java EE 5.0中，JSF(Java Server Faces)技术被放到了一个非常重要的地位。J2EE社区试图通过JSF来统一Web应用的开发模式与方法。

　　相对于传统的基于JSP/Servlet的开发模型，JSF能够带来许多好处，譬如：

　　可定制的丰富的UI组件

　　良好的事件响应机制

　　表达式语言(Expression Language)

　　表单数据的自动转换与验证

　　基于MVC的框架模型等等...

　　但同时我们也不得不看到，业界常见的JSF引擎普遍存在着一些缺陷与不足（并不是说JSF技术模型本身的局限，而是常规的实现机制所产生的一些问题），而这些不足将可能对JSF成为日后Web应用主流开发技术带来一定的负面影响，包括：

　　常规的JSF实现机制，运行期性能并不是非常理想

　　缺少良好的工具支持

　　作为JCP组织成员，金蝶中间件对待JSF技术又是如何思考的？是否打算对JSF进行全面支持？又是通过怎样的解决方案来克服上述不足的呢？

　　2.JSF与Ajax

　　一谈到Web开发技术，就不得不提Ajax。这是目前在整个IT界都红得发紫的概念了。在这里我想没必要再去阐述一遍什么是Ajax，但我们可以对Ajax有一个基本的认识。

　　Ajax其实是一种新瓶装旧酒的技术，它的好处是通过Java Script与DHTML，提供了一种异步编程模型，从而使我们的Web应用给客户带来更好的人机体验。但Ajax解决问题的层面很低；或者说，它解决问题的方法与手段，很难形成一种可高度抽象的框架级解决方案，而JSF则是一种可扩展的框架级解决方案。

　　事实上，我认为Ajax是一种过渡技术，相信在未来一到两年之内将被新的技术所代替，是微软的XAML、Mozilla的XUL、还是任何可能的RIA标准，实际上整个业界都在观望。但不管采用什么技术，JSF都能适应，对JSF来说适应一个新技术只是更换一个Render Kit而已。举一个例子，如果想在网页中实现图表功能（Chart)，MSIE有VML，Gecko和Opera有SVG，而在服务器端只需要简单地判断一下浏览器类型就可以选择一个Render Kit生成不同的markup来完成相同的功能，这是用常规JSP技术很难完成的任务。

　　3.Apusic JSF：中国人做出的JSF引擎

　　3.1 容器级别的Ajax支持

　　目前有JSF Ajax这种思路的，恐怕也不是金蝶中间件一家，但很多第三方的JSF Ajax实现是提供一个组件库以及一个附加的Servlet 或Filter来处理Ajax请求，而我们是直接由JSF容器来处理Ajax请求的。我们会根据请求的类型来判断这是一个正常的HTTP请求还是一个 Ajax请求。如果是一个常规HTTP请求就运行JSP页面，生成页面文档（并且我们会在生成的页面文档中嵌入Ajax所必须的Java Script代码，后文提及）；如果该请求是一个Ajax请求，服务器对请求参数正常解码，并执行JSF中除页面输出阶段以外的所有其他阶段，这时将生成一个JSF的组件树，遍历该组件树，从中找出发生变化的数据，并将这些数据打包成一个Ajax应答，并由客户端来更新这些修改的数据，甚至改变页面外观。

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

　　那么，这样能够带来怎样的好处呢？