??xml version="1.0" encoding="utf-8" standalone="yes"?>
3
q前Q?/span>
“Spring
之父
”Rod.Johnson
写了一本在
Java
界引赯动的书:?/span>
Expert One-on-One J2EE Development Without EJB
》。这本书阐述?/span>
EJB
作ؓ
J2EE
核心技术所带来的意义与价|但作者用了更大篇q介l?/span>
EJB
的一些缺陷与不Qƈ提出?/span>
Without EJB
的解x案。正是由?/span>
“J2EE Without EJB?/span>
q个Ȁ动h心的口号及这本书奠定的基
Q导致了
Spring Framework
q个l典轻量U框架的诞生?/span>
2
q前Q?/span>
Ajax
开始进入h们的视野。时至今日,
Ajax
已经成ؓ一个红得发紫的技术。但是今天,我想说一句:
JavaEE without Ajax
?/span>
Ajax
的“原|?/span>
Ajax
Z么这LQ有Q是因ؓ起了个好听易记的名字Q比如荷兰著名的
Ajax
球队Q即阿贾克斯Q;也有Q是因ؓ
Google
全新?/span>
Ajax
应用产品lh们带来的酷体验Q比如伟大的
Google Maps
?/span>
GMail
{)。确实如此,
Ajax
能够如此行的最主要原因是它带来了更好的用户体验,改变了h们对传统
Web
应用的不佛_象?/span>
然而,即
Ajax
的狂?/span>
Fans
也不得不承认的是Q从技术层面上来说Q?/span>
Ajax
q没有带来什么新鲜的东西。它本质上是一U新瓶装旧酒的技术,好处是通过
Java Script
?/span>
DHTML
提供了一U异步编E模型,从而
Web
应用l客户带来了更好的hZ验。正如我在去q?/span>
引v大家争论
的拙文?/span>
Ajax
Q只是一U过渡技术》中表述的:
Ajax
解决问题的层面较低。或者说Q它解决问题的方法与手段Q很隑Ş成一U可高度抽象的框架解决Ҏ。ƈ且,正是因ؓ
Ajax
Z
Java Script
Q因此不可避免地带来?/span>
Java Script
的诸多缺点,譬如Q?/span>
跨浏览器是一场噩?br />
We Love Java, Not Java Script
。套用毛泽东的惯用句式就是:
?/span>
?/span>
Java,
不要
Java Script?/span>
。相信很多读者看完这个标题也怼不以为然Q但q句话却代表了许?/span>
J2EE
开发h员的心声?/span>
众多
Java
工程师都?/span>
Java
有一U近乎偏执的喜爱Q他们热?/span>
Java
的简z与优雅。但一旦让他们去进?/span>
Java Script
的开发,却往往会不知所措:q度灉|的语法,无法通过~译器进行语法校验,~Z良好的调试工L{这些,都会让h们对
Java Script
畏手畏脚Q更遑论
Ajax
的开发?/span>
一句话Q?/span>
Java
C需?/span>
Ajax
Q需要它
来提升基?/span>
JavaEE
?/span>
Web
应用的hZ验;但是Qh们ƈ不喜?/span>
Ajax
目前的开发模式。无疑,我们需要一U新的解x案?/span>
谁来拯救
JavaEE
?/span>
Ajax
Q?/span>
我给出的{案?/span>
JSF
。目前,关于
JSF
的一U流行说法是“悲剧h生:
Sun
?/span>
JSF
光着w子降?/span>
Java Web
世界”。然而,我的看法却是Q作ZU革命性的服务器端lg技术,
JSF
犹如早晨八九炚w的太阻I前途不可限量?/span>
让事实说话,我们先来看看
JSF
h
/
响应q程的标准生命周期:
?/span>
1
Q?/span>
JSF
的生命周?/span>
通过上图可以观察刎ͼM一?/span>
JSF“Faces Request?
hQ经q?/span>
Restore View
?/span>
Apply Request Values
?/span>
Process Validations
?/span>
Update Models
?/span>
Invoke Application
{阶D以后,产生了一?/span>
“Render Response?
q回l客L。那么,常规
JSF
引擎是如何实Cq过E的呢?
<!--[if !vml]-->
?/span>
2
Q常?/span>
JSF
引擎的请求与响应q程
回顾一下常?/span>
JSF
引擎针对h与响应的q程Q首先,客户端请求某个资源,产生一?/span>
Faces Request
Q服务器端接收到此请求以后,l过一pd后台处理Q生一?/span>
Faces Response
。我们注意到Q响应的
Content-Type
?/span>
text/html
Q而生的内容M是一D?/span>
HTML
文本Q浏览器在接收到
HTML
文本以后Q进行整个页面的渲染与刷新?/span>
无需?/span>
Ajax
代码?/span>
Ajax Enabled
应用
我用自己开发的
JSF
引擎Q这样处理上q过E(详见参考资?/span>
www.
OperaMasks.org
Q?/span>
Q如下图所C:
<!--[if !vml]-->
?/span>
3
Q?/span>
OperaMasks JSF
实现的请求与响应q程
首先可以观察刎ͼ
Faces Request
的发出是Z
“x-requested-by: XML Http Request?/span>
Q也是_q是一?/span>
Ajax
hQ而该h在到达服务器端以后,服务器端所产生?/span>
Faces Response
同常?/span>
Faces Response
相比也发生了变化Q?/span>
Content-Type
不再?/span>
text/html
Q变成了
text/javascript
Qƈ且,响应的主体也不再?/span>
html
文本Q而是一?/span>
script
脚本。浏览器在接收到响应以后Q再也不需要进行整个页面的渲染与刷斎ͼ而只仅仅需要执行这D脚本内容,页面的控gq行更新卛_?/span>
显而易见,通过
上述
JSF
技术,我们获得了:
ZAjax的请求、应{、及面控g的更?br />
]]>
Ҏ索引擎的支持不好
q掉了Back、History{按钮(管我ƈ不认为Back、History是什么好东西Q?br />
开发与l护成本q高
<!--[endif]--> <!--[endif]-->
<!--[endif]-->
数据传输量明昑և?br />
避免整个面的刷斎ͼ更好的用户体?br />
pȝ保持敏捷、高?span lang="EN-US" style="FONT-SIZE: 10.5pt; FONT-FAMILY: Arial">
<!--[if !supportLists]--><!--[endif]-->
换言之:M标准
JSF
应用Q只需其?/span>
OperaMasks JSF
引擎上运行,可以达到这L效果。我们ƈ没有写Q何一?/span>
Ajax
的代码,但是Q我们的应用却是自然而然?/span>
Ajax Enabled
的应用。大道至Q大象无形?/span>
奥妙所在:
JSF
?/span>
Render
机制
Z么可以这P
JSF
lg只是特定状态和行ؓ的蝲体,而组件以什么Ş式去和用户交互,是完全可定制的、独立于该特定的表现语言Q可以是
HTML
?/span>
WML
或者其他Ş式;具体是什么,可以通过指定
JSF
lg?/span>
Render Kit
来实玎ͼ而每一U?/span>
Render Kit
Q对应于lg作者写的同一风格和Ş式的一pd
Render
?/span>
比如Q如果想在网中实现图表功能Q?/span>
Chart)
Q?/span>
MSIE
?/span>
VML
Q?/span>
Gecko
?/span>
Opera
?/span>
SVG
Q而在服务器端只需要简单地判断一下浏览器cdQ就可以选择一?/span>
Render Kit
Q?/span>
生成不同的客L表现来完成相同功能――这是用常规
JSP
技术很隑֮成的d?/span>
通俗的说Q?/span>
JSF
lg可以译成Q何你惌的Ş式?/span>
So
Q?/span>
JSF
框架比现有其它开源框架具有更强的生命力。上文所q的
OperaMasks JSF
Q其容器U别
Ajax
实现Q正是灵zd?/span>
Render Kit
的具体案例?/span>
从容器别对
Ajax
予以支持?/span>
JSF
引擎
我们提出?/span>
JSF
是直接由
JSF
容器来处?/span>
Ajax
h的,它会Ҏhcd来判断这是一个正?/span>
HTTP
hq是一?/span>
Ajax
hQ如果是常规
HTTP
hp?/span>
JSP
面Q生成页面文档(特定的,对于
Ajax Render kit
Q要加入一?/span>
Ajax
基础
JavaScript
代码Q;如果?/span>
Ajax
hQ服务器对请求参数正常解码,q执?/span>
JSF
中除面输出阶段以外的所有其他阶D,生成一?/span>
JSF
lg树?/span>
一直到q一步ؓ止,处理方式与对普?/span>
HTTP
h的处理完全一_唯一不同的是Q在随后
Render Response
阶段Q容器除了调用组件作者写?/span>
Ajax
功能
Renderer
以外Q更重要的是在生成响应页面时Q会qo掉一切不会变化的静态内容――也是_静态内容不会生成到响应面中去Q而对每一个动态内容则会生成一个相?/span>
JavaScript
代码Q可以更q一步优化ؓ只有变化了的动态内Ҏ处理Q。这P传给客户?/span>
Ajax
应答实际上是p样一?/span>
JavaScript
语句构成。在
Ajax
响应q回到客LӞ可以自动由
Ajax
回调函数执行q些
JavaScript
语句Q完成对面x的、局部的更改Q而不需要刷新整个页面。依?/span>
JSF
lg的具体功能,甚至可以改变面的外观。而整?/span>
Ajax
机制?/span>
JSF
引擎提供Q对用户完全透明?/span>
实际上,?/span>
JSF
规范?/span>
JSF
面输出阶段所采用?/span>
Render Kit
是可替换的,默认?/span>
HTML_BASIC Render Kit
输出的是标准
HTML
语法Q不包含M
Java Script
代码?/span>
我们提出?/span>
JSF
引擎实现了一?/span>
Ajax Render Kit
Q可以在
HTML
文中嵌?/span>
Java Script
代码来实?/span>
Ajax
Ҏ,而替?/span>
Render Kit
只需要修攚w|文件即可?/span>
单地_
q种
JSF
引擎为每个标准组仉实现了相应的
Ajax Render
Q?/span>
比如?/span>
UICommand
lgQ其
Ajax Render
会在
onclick
事g中加?/span>
JavaScript
?/span>
Ajax
提交代码Q向服务器提?/span>
Ajax
h。通过q种方式QQ何一个包含标?/span>
JSF
lg?/span>
Web
应用Q都可以通过只更?/span>
Render Kit
配置?/span>
Ajax
来实?/span>
Web
应用
Ajax
化。而对于第三方的组Ӟ可能本nq不支持
Ajax
Q但使用一个名?/span>
<Ajax:renderGroup>
的标{,可以立卛_q个W三方组件{换成
Ajax Enabled
?/span>
例如Q?/span>
Apache myfaces
?/span>
Tomahawk
目提供了一?/span>
Tree
lgQ这个组件本wƈ不支?/span>
Ajax
Q每当按下一?/span>
Tree
l点都将重新h整个面。?/span>
<Ajax:renderGroup>
标签后,则只h
Tree
部分Q而不h面的其他部分。当然更好的方式是,提供一个本w就支持
Ajax
?/span>
Tree
lgQ以减少冗余数据的传递。关?/span>
<Ajax:renderGroup>
标签的原理,有兴的读者可以参?/span>
OperaMasks JSF
的源码(详见参考资料)Q这里就不再一一赘述了?/span>
因此Q我们认为: JavaEE Without Ajax!