如今每一个使用servletsde开发者都知道JSP,一种由Sun公司发明并花费大量精力加以推行并建构在servlet技术之上deweb技术.JSP将servlet中dehtml相关代码脱离了出来,从而可以加速web应用开发和页面维护.实际上,由Sun发布de官方”应用开发模型”文档上说得更远: “JSP技术应该被视为标准,而servlets在多数情况下可视为一种补充.” ( Section 1.9, 1999/12/15听取意见版 ).
本文de目de在于听取对该申明de合理性de评估 — 通过比较JSP和另一项基于servletsde技术: template engines(模板引擎).
直接使用Servletsde问题
起初,servlets被发明,整个世界都看到了它de优越.基于servletde动态网页可以被快速执行,可以在多个服务器之间轻易转移, 并且可以和后台数据库完美地集成. Servlets被广泛接受成为一种web服务器端de首选平台.
但是,通常通过简单方式即可实现dehtml相关代码现在却要让程序员通过 out.println()调用每一行HTML行,这在实际de servlet应用中成为了一个严重问题. HTML内容不得不通过相关代码来实现, 对于大deHTML页来说不啻是一项繁重费时de工作.另外,负责网页内容de人员不得不请开发人员来进行所有de更新.为此,人们寻求这一种更好de解决方式.
JSP到!
JSP 0.90出现了.在这种技术中您可以将Java相关代码嵌入到HTML文件,服务器将自动为页面创建一个 servlet. JSP被认为是一种写servletde简易方式.所有HTML可以直接得到而不必通过out.println()调用,而负责页面内容de人员可以直接修改HTML而不必冒破坏Java相关代码de风险.
但是,让页面美术设计师和开发人员在同一文件上工作并不理想,让Java嵌入HTML被证明是就象将HTML 嵌入Java一样令人尴尬.读取一堆很乱de相关代码仍然是一件困难de事情.
于是,人们在使用jsp方面变得成熟,更多地使用了JavaBeans. Beans包含了jsp所需de业务逻缉相关代码.JSP中de大多数相关代码都可以取出来放到bean中去,而只留下极少de标记用于调用bean.
最近,人们开始认为这种方式下deJSP页面真de很象是视图(view).它们成为一个用于显示客户端请求de结果de组件.于是人们会想,为什么不直接对view发送请求呢? 目标view如果对该请求不合适又将如何? 说到底,很多de请求有多种可能来取得结果view视图.例如,同一请求可能产生成功de页面,数据库例外出错报告,或者是缺少参数de出错报告.同一请求可能产生一个英文页面也可能是西班牙文页面,这取决于客户端delocale.为什么客户端必须直接将请求发送给view?为什么客户端不应该将请求发送给一些通用de服务器组件并让服务器来决定JSP viewde返回?
这使很多人接受了已被称为”Model 2″de设计, 这是在JSP 0.92中定义de基于model-view-controllerde模型.在这种设计中,请求被发送到一个servlet控制器,它执行了商业逻缉并产生一个相近de数据”model”来用于显示.这一数据随后通过内部送到一个JSP “view”来进行显示,这样看起来JSP页就象是一个普通de嵌入deJavaBean. 可以根据负责控制deservletde内部逻辑来选择适当deJSP页面进行显示.这样,JSP文件成为了一个漂亮detemplate view.这就是另一种发展,并被另外一些开发者所推崇至今.
进入Template Engines
使用template engine来代替通常目dedeJSP, 接下去de设计将变得简单,语法更简单,出错信息更易读,工具也更用户化. 一些公司已经做了这样de引擎,最著名de可能是WebMacro (http://webmacro.org, from Semiotek),他们de引擎是免费de.
开发者应该明了,选定一个template engine来取代JSP提供了这么一些技术优势,这也正是jspde一些不足之处:
问题 #1: Java相关代码太模板化了
虽然被认为是不好de设计,JSP仍试图将Java相关代码加入web页面.这有些象是Java曾经做de,即对C de简化修改,template engines也通过将jsp中de较低层de源码移去来使之简化.Template engines实行了更好de设计.
问题 #2: 要求Java相关代码
在JSP页中要求写一些Java相关代码.例如,假设某页要决定当前web应用中根de上下文从而导向其主页,
在JSP中最好使用如下Java相关代码:
<a href=”<%= request.getContextPath() %>/index.html”>Home page</a>
您可以试图避免 Java相关代码,而使用 <jsp:getProperty> 标记但这将给您六下难以阅读de字串:
<a href=”<jsp:getProperty name=”request”
property=”contextPath”/>/index.html”>HomePage</a>
使用template engine则没有Java相关代码和难看de语法.这里是同样要求下在WebMacro中de写法:
<a href=”$Request.ContextPath;/index.html”>Home page</a>
在WebMacro中, ContextPath 作为 $Request变量de一个属性,使用类似Perlde语法.其它er template engines使用了其它de语法类型.
再看另 一个例子,假设一个高级de”view”需要设定一个cookie来记录用户缺省de颜色配置 — 这种任务看起来大概只能由view而不是servlet控制器来完成.在JSP中要有这样deJava相关代码:
<% Cookie c = new Cookie(”colorscheme”, “blue”); response.addCookie(c); %>
在WebMacro中则没有Java相关代码:
#set $Cookie.colorscheme = “blue”
作为最后一个离子,假如又要重新找回原来decookie中de颜色配置.对于JSP,我可以认为也有一个相应de工具类来提供帮助,因为用getCookies()直接做这样低层de会变得可笑而且困难.在JSP中:
<% String colorscheme = ServletUtils.getCookie(request, “colorscheme”); %>
在WebMacro中没有对工具类de需要,通常是:$Cookie.colorscheme.Value .对写jspde图形艺术师,又是哪一种语法更容易学习呢?
JSP 1.1 引入了自定义标记(custom tags)允许任意de和HTML相似de标记在JSP页面中在后台执行Java相关代码,这将具有一定de价值,但前提是要有一个广泛知晓de,全功能de,可以免费得到de,标准化de标记库.目前还没有出现这样de标记库.
问题 #3: 简单工作仍然很累人
即使是很简单de工作,例如包含 header和 footer,在JSP中仍然很很困难. 假设有一个 “header”和一个 “footer”模板要包含到所有页面,而每一个模板要在content中包含当前de页标题.
在JSP中最佳办法是:
<% String title = “The Page Title”; %>
<%@ include file=”/header.jsp” %>
…您de页面内容…
<%@ include file=”/footer.jsp” %>
页面设计者要记住不能遗漏第一行de分号并要将title定义为一个字符串.此外, /header.jsp和/footer.jsp必须在根目录下并且必须是可存取de完整文件.
在WebMacro中包含headers和footers做起来比较简单:
#set $title = “The Page Title”
#parse “header.wm”
Your content here
#parse “footer.wm”
这里对设计者来说没有要牢记de分号或对titlede定义, .wm文件可以放在可自定义de搜索路径下.
问题 #4: 很粗de循环
在JSP中循环很困难.这里是用JSP重复打印出每一个ISP对象名字.
<%
Enumeration e = list.elements();
while (e.hasMoreElements()) {
out.print(”The next name is “);
out.println(((ISP)e.nextElement()).getName());
out.print(”<br>”);
}
%>
也许什么时候会有用户自定义标记来做这些循环.对”if”也是如此.JSP页可能看上去成了很古怪dejava相关代码.而同时,webmacro循环很漂亮:
#foreach $isp in $isps {
The next name is $isp.Name <br>
}
如果必要de话,#foreach指令可被自定义de #foreach-backwards指令很容易地取代.
用jspde话很可能变这样:(这里是一个可能de <foreach>标记)
<foreach item=”isp” list=”isps”>
The next name is <jsp:getProperty name=”isp” property=”name”/> <br>
</foreach>
设计者当然地回选择前者.
问题 #5: 无用de出错信息
JSP常有一些令人惊讶de出错信息.这是因为页面首先被转换成为一个servlet然后才进行编译.好deJSP 工具可以相对增加找到出错位置de可能性,但即使是最好de工具也无法使所有出错信息都能容易地被读懂.由于转化de过程,一些错误对工具来说可能根本不可能被识别.
例如,假设JSP页面需要建立一个对所有页通用de标题.以下相关代码并没有错:
<% static String title = “Global title”; %>
但Tomcat会提供以下出错信息:
work/:8080//JC_0002ejspJC_jsp_1.java:70: Statement expected.
static int count = 0;
^
此信息认为以上脚本被放入 _jspService()方法而静态变量不允许放入方法中.该语法应该是 <%! %>.页面设计者很难读懂这些出错信息.即使最好de平台在这方面也做得很不够.即使所有 Java相关代码都从页中移出也无法解决问题.另外,以下表达式有什么错?
<% count %>
tomcat给出:
work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: Class count not found in
type declaration.
count
^
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: Invalid declaration.
out.write(”\r\n”);
^
换句话说,只是遗失了一个标记而已.应该是 <%= count %>.
由于template engine可以在template文件中直接产生而没有任何戏剧性de向相关代码转化,所以可以非常容易地给出适当de出错报告. 依次类推,当c语言de命令被打入Unix shellde命令行, 您并不希望shell 会生成一个C程序来运行这个命令,而只是需要shell简单地解释命令并加以执行,如有错误也直接给出.
问题 #6: 需要一个编译器
JSP需要一个置放在webserver中de编译器.由于Sun拒绝放弃包含了他们dejavac编译器detools.jar库, 这其中就变得有问题了.Web服务器可以包含进一个第三方de编译器如ibmde jikes.但这样de编译器并不能在所有平台上顺利工作(用 C 写成de) 也不利于建立纯Java deweb服务器. JSP有一个预编译选项可以起到一定作用,尽管并不完美.
问题 #7: 空间de浪费
JSP消耗了额外de内存和硬盘空间.对服务器上每30KdeJSP文件,必须要有相应de大于30Kde类文件产生.实际上使得硬盘空间加倍.考虑到JSP文件随时可以很容易地通过 <%@ include>包含一个大de数据文件,这样de关注有着很现实de意义.同时,每一个JSPde类文件数据必须加载到服务器de内存中,这意味着服务器de内存必须永远地将整个JSP文档树保存下去.少数一些JVM有能力将类文件数据从内存中移去;但是,程序员通常无法控制这样de规则来重新申明,而且对大de站点来说重新申明可能不是很有效.对template engines由于没有产生第二个文件,所以节省了空间.Template engines还为程序员提供对templates在内存中进行缓存de完全控制.
使用template engine也有一些问题:
Templatede问题 #1: 没有严格定义
template engine该如何工作并没有严格定义.可是,但相对jsp来说,其实这并不很重要,和 JSP不同de是,template engines对web服务器没有任何特殊要求 — 任何支持servletde服务器都可以支持template engines (包括API 2.0服务器如Apache/JServ,它们并不能完全支持 JSP)! 如果为最好detemplate engine设计提供健康de竞争本可以引起一场耀眼de革新,特别是有开放源码de促进,(可以让思想相互推动和促进),那么今天deWebMacro就会象Perl一样,没有严格定义但公开源码组织de推动就是它de标准.
Templatede问题 #2: 没有获得公认
Template engines并未被广泛知晓.JSP已经占据了极大de商业市场,并且深入人心.而使用g template engines只能是一种未被了解de替代技术.
Templatede问题 #3: 尚未调配好
Template engines还没有被高度地调配好.没有对template engine 和JSP两者进行性能测试和比较.理论上说一个调配完好detemplate engine实现应该和一个调配好deJSP相匹配;但是,考虑到第三方为jsp已经作出了这么深远de推动,结果只有jsp被很好地调配好了.
JSPde角色
当然地,JSP在将来必然会有其地位.即使从名称上也可以看出JSP和ASPde相似性,它们只有一个字母de差别.所以如果要让使用aspde人们转向java,非常相似dejsp环境将对此起到很大de推动作用,和asp保持这种对应关系所能起到de作用应该也是被推出jspde设计者重点考虑到de.
然而这里想要强调de一点是:有利于转入新环境de工作者,以及实际上是否是使用该环境de最佳方式,这两者是有很大不同de.
JSP日益显示出它正成为最重要dejava技术之一, 它让人们离开ASPde世界 — 由此,Sun将支持这一强有力de商业case, Java相关技术支持者也将给予更大力de支持.
可是,这并非java平台de最佳解决方案.这将使java解决方案变得好象是没有javade解决方案了.