如今每一個(gè)使用servlets的開(kāi)發(fā)者都知道JSP，一種由Sun公司發(fā)明并花費大量精力加以推行并建構在servlet技術(shù)之上的web技術(shù)。JSP將servlet中的html代碼脫離了出來(lái)，從而可以加速web應用開(kāi)發(fā)和頁(yè)面維護。實(shí)際上，由Sun發(fā)布的官方"應用開(kāi)發(fā)模型"文檔上說(shuō)得更遠： "JSP技術(shù)應該被視為標準，而servlets在多數情況下可視為一種補充。" ( Section 1.9, 1999/12/15聽(tīng)取意見(jiàn)版 )。
本文的目的在于聽(tīng)取對該申明的合理性的評估 -- 通過(guò)比較JSP和另一項基于servlets的技術(shù)： template engines（模板引擎）。
直接使用Servlets的問(wèn)題
起初，servlets被發(fā)明，整個(gè)世界都看到了它的優(yōu)越?；趕ervlet的動(dòng)態(tài)網(wǎng)頁(yè)可以被快速執行，可以在多個(gè)服務(wù)器之間輕易轉移， 并且可以和后臺數據庫完美地集成。 Servlets被廣泛接受成為一種web服務(wù)器端的首選平臺。
但是，通常通過(guò)簡(jiǎn)單方式即可實(shí)現的html代碼現在卻要讓程序員通過(guò) out.println()調用每一行HTML行，這在實(shí)際的 servlet應用中成為了一個(gè)嚴重問(wèn)題。 HTML內容不得不通過(guò)代碼來(lái)實(shí)現, 對于大的HTML頁(yè)來(lái)說(shuō)不啻是一項繁重費時(shí)的工作。另外，負責網(wǎng)頁(yè)內容的人員不得不請開(kāi)發(fā)人員來(lái)進(jìn)行所有的更新。為此，人們尋求這一種更好的解決方式。
JSP到！
JSP 0.90出現了。在這種技術(shù)中你可以將Java代碼嵌入到HTML文件，服務(wù)器將自動(dòng)為頁(yè)面創(chuàng )建一個(gè) servlet。 JSP被認為是一種寫(xiě)servlet的簡(jiǎn)易方式。所有HTML可以直接得到而不必通過(guò)out.println()調用，而負責頁(yè)面內容的人員可以直接修改HTML而不必冒破壞Java代碼的風(fēng)險。
但是，讓頁(yè)面美術(shù)設計師和開(kāi)發(fā)人員在同一文件上工作并不理想，讓Java嵌入HTML被證明是就象將HTML 嵌入Java一樣令人尷尬。讀取一堆很亂的代碼仍然是一件困難的事情。
于是，人們在使用jsp方面變得成熟，更多地使用了JavaBeans。 Beans包含了jsp所需的業(yè)務(wù)邏緝代碼。JSP中的大多數代碼都可以取出來(lái)放到bean中去，而只留下極少的標記用于調用bean。
最近，人們開(kāi)始認為這種方式下的JSP頁(yè)面真的很象是視圖（view）。它們成為一個(gè)用于顯示客戶(hù)端請求的結果的組件。于是人們會(huì )想，為什么不直接對view發(fā)送請求呢？ 目標view如果對該請求不合適又將如何？ 說(shuō)到底，很多的請求有多種可能來(lái)取得結果view視圖。例如，同一請求可能產(chǎn)生成功的頁(yè)面，數據庫例外出錯報告，或者是缺少參數的出錯報告。同一請求可能產(chǎn)生一個(gè)英文頁(yè)面也可能是西班牙文頁(yè)面，這取決于客戶(hù)端的locale。為什么客戶(hù)端必須直接將請求發(fā)送給view?為什么客戶(hù)端不應該將請求發(fā)送給一些通用的服務(wù)器組件并讓服務(wù)器來(lái)決定JSP view的返回?
這使很多人接受了已被稱(chēng)為"Model 2"的設計, 這是在JSP 0.92中定義的基于model-view-controller的模型。在這種設計中，請求被發(fā)送到一個(gè)servlet控制器，它執行了商業(yè)邏緝并產(chǎn)生一個(gè)相近的數據"model"來(lái)用于顯示。這一數據隨后通過(guò)內部送到一個(gè)JSP "view"來(lái)進(jìn)行顯示，這樣看起來(lái)JSP頁(yè)就象是一個(gè)普通的嵌入的JavaBean。 可以根據負責控制的servlet的內部邏輯來(lái)選擇適當的JSP頁(yè)面進(jìn)行顯示。這樣，JSP文件成為了一個(gè)漂亮的template view。這就是另一種發(fā)展，并被另外一些開(kāi)發(fā)者所推崇至今.
進(jìn)入Template Engines
使用template engine來(lái)代替通常目的的JSP, 接下去的設計將變得簡(jiǎn)單，語(yǔ)法更簡(jiǎn)單，出錯信息更易讀，工具也更用戶(hù)化。 一些公司已經(jīng)做了這樣的引擎，最著(zhù)名的可能是WebMacro (http://webmacro.org, from Semiotek)，他們的引擎是免費的。
開(kāi)發(fā)者應該明了，選定一個(gè)template engine來(lái)取代JSP提供了這么一些技術(shù)優(yōu)勢，這也正是jsp的一些不足之處：
問(wèn)題 #1: Java代碼太模板化了
雖然被認為是不好的設計，JSP仍試圖將Java代碼加入web頁(yè)面。這有些象是Java曾經(jīng)做的，即對C++的簡(jiǎn)化修改，template engines也通過(guò)將jsp中的較低層的源碼移去來(lái)使之簡(jiǎn)化。Template engines實(shí)行了更好的設計。
問(wèn)題 #2: 要求Java代碼
在JSP頁(yè)中要求寫(xiě)一些Java代碼。例如，假設某頁(yè)要決定當前web應用中根的上下文從而導向其主頁(yè)，
在JSP中最好使用如下Java代碼：
?。糰 href="＜%= request.getContextPath() %＞/index.html"＞Home page＜/a＞
你可以試圖避免 Java代碼，而使用 ＜jsp:getProperty＞ 標記但這將給你六下難以閱讀的字串：
?。糰 href="＜jsp:getProperty name="request"
property="contextPath"/＞/index.html"＞HomePage＜/a＞
使用template engine則沒(méi)有Java代碼和難看的語(yǔ)法。這里是同樣要求下在WebMacro中的寫(xiě)法：
?。糰 href="$Request.ContextPath;/index.html"＞Home page＜/a＞
在WebMacro中, ContextPath 作為 $Request變量的一個(gè)屬性，使用類(lèi)似Perl的語(yǔ)法。其它er template engines使用了其它的語(yǔ)法類(lèi)型。
再看另 一個(gè)例子，假設一個(gè)高級的"view"需要設定一個(gè)cookie來(lái)記錄用戶(hù)缺省的顏色配置 -- 這種任務(wù)看起來(lái)大概只能由view而不是servlet控制器來(lái)完成。在JSP中要有這樣的Java代碼：
?。? Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c); %＞
在WebMacro中則沒(méi)有Java代碼：
#set $Cookie.colorscheme = "blue"
作為最后一個(gè)離子，假如又要重新找回原來(lái)的cookie中的顏色配置。對于JSP，我們可以認為也有一個(gè)相應的工具類(lèi)來(lái)提供幫助，因為用getCookies()直接做這樣低層的會(huì )變得可笑而且困難。在JSP中：
?。? String colorscheme = ServletUtils.getCookie(request, "colorscheme"); %＞
在WebMacro中沒(méi)有對工具類(lèi)的需要，通常是：$Cookie.colorscheme.Value ．對寫(xiě)jsp的圖形藝術(shù)師，又是哪一種語(yǔ)法更容易學(xué)習呢？
JSP 1.1 引入了自定義標記（custom tags）允許任意的和HTML相似的標記在JSP頁(yè)面中在后臺執行Java代碼，這將具有一定的價(jià)值，但前提是要有一個(gè)廣泛知曉的，全功能的，可以免費得到的，標準化的標記庫。目前還沒(méi)有出現這樣的標記庫。
問(wèn)題 #3: 簡(jiǎn)單工作仍然很累人
即使是很簡(jiǎn)單的工作，例如包含 header和 footer，在JSP中仍然很很困難。 假設有一個(gè) "header"和一個(gè) "footer"模板要包含到所有頁(yè)面，而每一個(gè)模板要在content中包含當前的頁(yè)標題。
在JSP中最佳辦法是：
?。? String title = "The Page Title"; %＞
?。?@ include file="/header.jsp" %＞
...你的頁(yè)面內容...
?。?@ include file="/footer.jsp" %＞
頁(yè)面設計者要記住不能遺漏第一行的分號并要將title定義為一個(gè)字符串。此外， /header.jsp和/footer.jsp必須在根目錄下并且必須是可存取的完整文件。
在WebMacro中包含headers和footers做起來(lái)比較簡(jiǎn)單：
#set $title = "The Page Title"
#parse "header.wm"
Your content here
#parse "footer.wm"
這里對設計者來(lái)說(shuō)沒(méi)有要牢記的分號或對title的定義， .wm文件可以放在可自定義的搜索路徑下。
問(wèn)題 #4: 很粗的循環(huán)
在JSP中循環(huán)很困難。這里是用JSP重復打印出每一個(gè)ISP對象名字。
?。?
Enumeration e = list.elements();
while (e.hasMoreElements()) {
out.print("The next name is ");
out.println(((ISP)e.nextElement()).getName());
out.print("＜br＞");
}
%＞
也許什么時(shí)候會(huì )有用戶(hù)自定義標記來(lái)做這些循環(huán)。對"if"也是如此。JSP頁(yè)可能看上去成了很古怪的java代碼。而同時(shí)，webmacro循環(huán)很漂亮：
#foreach $isp in $isps {
The next name is $isp.Name ＜br＞
}
如果必要的話(huà)，#foreach指令可被自定義的 #foreach-backwards指令很容易地取代。
用jsp的話(huà)很可能變這樣：（這里是一個(gè)可能的 ＜foreach＞標記）
?。糵oreach item="isp" list="isps"＞
The next name is ＜jsp:getProperty name="isp" property="name"/＞ ＜br＞
?。?foreach＞
設計者當然地回選擇前者。
問(wèn)題 #5: 無(wú)用的出錯信息
JSP常有一些令人驚訝的出錯信息。這是因為頁(yè)面首先被轉換成為一個(gè)servlet然后才進(jìn)行編譯。好的JSP 工具可以相對增加找到出錯位置的可能性，但即使是最好的工具也無(wú)法使所有出錯信息都能容易地被讀懂。由于轉化的過(guò)程，一些錯誤對工具來(lái)說(shuō)可能根本不可能被識別。
例如，假設JSP頁(yè)面需要建立一個(gè)對所有頁(yè)通用的標題。以下代碼并沒(méi)有錯：
?。? static String title = "Global title"; %＞
但Tomcat會(huì )提供以下出錯信息：
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Statement expected.
static int count = 0;
^
此信息認為以上腳本被放入 _jspService()方法而靜態(tài)變量不允許放入方法中。該語(yǔ)法應該是 ＜%! %＞。頁(yè)面設計者很難讀懂這些出錯信息。即使最好的平臺在這方面也做得很不夠。即使所有 Java代碼都從頁(yè)中移出也無(wú)法解決問(wèn)題。另外，以下表達式有什么錯？
?。? 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");
^
換句話(huà)說(shuō)，只是遺失了一個(gè)標記而已。應該是 ＜%= count %＞。
由于template engine可以在template文件中直接產(chǎn)生而沒(méi)有任何戲劇性的向代碼轉化，所以可以非常容易地給出適當的出錯報告。 依次類(lèi)推，當c語(yǔ)言的命令被打入Unix shell的命令行， 你并不希望shell 會(huì )生成一個(gè)C程序來(lái)運行這個(gè)命令，而只是需要shell簡(jiǎn)單地解釋命令并加以執行，如有錯誤也直接給出。
問(wèn)題 #6: 需要一個(gè)編譯器
JSP需要一個(gè)置放在webserver中的編譯器。由于Sun拒絕放棄包含了他們的javac編譯器的tools.jar庫， 這其中就變得有問(wèn)題了。Web服務(wù)器可以包含進(jìn)一個(gè)第三方的編譯器如ibm的 jikes。但這樣的編譯器并不能在所有平臺上順利工作(用 C++寫(xiě)成的) 也不利于建立純Java 的web服務(wù)器。 JSP有一個(gè)預編譯選項可以起到一定作用，盡管并不完美。
問(wèn)題 #7: 空間的浪費
JSP消耗了額外的內存和硬盤(pán)空間。對服務(wù)器上每30K的JSP文件，必須要有相應的大于30K的類(lèi)文件產(chǎn)生。實(shí)際上使得硬盤(pán)空間加倍?？紤]到JSP文件隨時(shí)可以很容易地通過(guò) ＜%@ include＞包含一個(gè)大的數據文件，這樣的關(guān)注有著(zhù)很現實(shí)的意義。同時(shí)，每一個(gè)JSP的類(lèi)文件數據必須加載到服務(wù)器的內存中，這意味著(zhù)服務(wù)器的內存必須永遠地將整個(gè)JSP文檔樹(shù)保存下去。少數一些JVM有能力將類(lèi)文件數據從內存中移去；但是，程序員通常無(wú)法控制這樣的規則來(lái)重新申明，而且對大的站點(diǎn)來(lái)說(shuō)重新申明可能不是很有效。對template engines由于沒(méi)有產(chǎn)生第二個(gè)文件，所以節省了空間。Template engines還為程序員提供對templates在內存中進(jìn)行緩存的完全控制。
使用template engine也有一些問(wèn)題：
Template的問(wèn)題 #1: 沒(méi)有嚴格定義
template engine該如何工作并沒(méi)有嚴格定義?？墒?，但相對jsp來(lái)說(shuō)，其實(shí)這并不很重要，和 JSP不同的是，template engines對web服務(wù)器沒(méi)有任何特殊要求 -- 任何支持servlet的服務(wù)器都可以支持template engines (包括API 2.0服務(wù)器如Apache/JServ，它們并不能完全支持 JSP)! 如果為最好的template engine設計提供健康的競爭本可以引起一場(chǎng)耀眼的革新，特別是有開(kāi)放源碼的促進(jìn)，（可以讓思想相互推動(dòng)和促進(jìn)），那么今天的WebMacro就會(huì )象Perl一樣，沒(méi)有嚴格定義但公開(kāi)源碼組織的推動(dòng)就是它的標準。
Template的問(wèn)題 #2: 沒(méi)有獲得公認
Template engines并未被廣泛知曉。JSP已經(jīng)占據了極大的商業(yè)市場(chǎng)，并且深入人心。而使用g template engines只能是一種未被了解的替代技術(shù)。
Template的問(wèn)題 #3: 尚未調配好
Template engines還沒(méi)有被高度地調配好。沒(méi)有對template engine 和JSP兩者進(jìn)行性能測試和比較。理論上說(shuō)一個(gè)調配完好的template engine實(shí)現應該和一個(gè)調配好的JSP相匹配；但是，考慮到第三方為jsp已經(jīng)作出了這么深遠的推動(dòng)，結果只有jsp被很好地調配好了。
JSP的角色
當然地，JSP在將來(lái)必然會(huì )有其地位。即使從名稱(chēng)上也可以看出JSP和ASP的相似性，它們只有一個(gè)字母的差別。所以如果要讓使用asp的人們轉向java,非常相似的jsp環(huán)境將對此起到很大的推動(dòng)作用，和asp保持這種對應關(guān)系所能起到的作用應該也是被推出jsp的設計者重點(diǎn)考慮到的。
然而這里想要強調的一點(diǎn)是：有利于轉入新環(huán)境的工作者，以及實(shí)際上是否是使用該環(huán)境的最佳方式，這兩者是有很大不同的。
JSP日益顯示出它正成為最重要的java技術(shù)之一， 它讓人們離開(kāi)ASP的世界 -- 由此，Sun將支持這一強有力的商業(yè)case, Java相關(guān)技術(shù)支持者也將給予更大力的支持。
可是，這并非java平臺的最佳解決方案。這將使java解決方案變得好象是沒(méi)有java的解決方案了。
聯(lián)系客服
