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 />
Ҏ索引擎的支持不好
q掉了Back、History{按钮（管我ƈ不认为Back、History是什么好东西Q?br />
开发与l护成本q高
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程的标准生命周期：
<!--[endif]-->
?/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]-->
<!--[endif]-->
?/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]-->
<!--[endif]-->
?/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 />
数据传输量明昑և?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!
]]>