🎶 Sym - 一款用 Java 实现的现代化社区(论坛/BBS/社交网络/博客)平台

📕 思源笔记 - 一款桌面端笔记应用,支持 Windows、Mac 和 Linux

🎸 Solo - B3log 分布式社区的博客端节点,欢迎加入下一代社区网络

♏ Vditor - 一款浏览器端的 Markdown 编辑器

JSP/Servlet/JSF:JavaEE 不再需要 Ajax

作者: thesixthday,  出处:赛迪网技术社区, 责任编辑: 李春禹,
2007-12-27 13:21
  浏览器在接收到响应以后,再也不需要进行整个页面的渲染与刷新,而只仅仅需要执行这段脚本内容,将页面的控件进行更新即可。更好的方式是,提供一个本身就支持Ajax的Tree组件,以减少冗余数据的传递。

  3年前,“Spring之父”Rod.Johnson写了一本在Java界引起轰动的书:《Expert One-on-One J2EE Development Without EJB》。这本书阐述了EJB作为J2EE核心技术所带来的意义与价值,但作者用了更大篇幅介绍EJB的一些缺陷与不足,并提出了Without EJB的解决方案。正是由于“J2EE Without EJB”这个激动人心的口号及这本书奠定的基础,导致了Spring Framework这个经典轻量级框架的诞生。

  2年前,Ajax开始进入人们的视野。时至今日,Ajax已经成为一个红得发紫的技术。但是今天,我想说一句:JavaEE without Ajax。

  Ajax的“原罪”

  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引擎是如何实现上述过程的呢?

 浏览器在接收到响应以后,再也不需要进行整个页面的渲染与刷新,而只仅仅需要执行这段脚本内容,将页面的控件进行更新即可。更好的方式是,提供一个本身就支持Ajax的Tree组件,以减少冗余数据的传递。

  

  图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应用。

  因此,我们认为:JavaEE Without Ajax!


欢迎注册黑客派社区,开启你的博客之旅。让学习和分享成为一种习惯!

留下你的脚步