（編者：這篇文章的原文首次在國外出現(xiàn)時，JSP還只是一種剛剛嶄露頭角的技術，并沒有像現(xiàn)在這樣如日中天�，F(xiàn)在看來這篇文章的某些觀點可能會有一定的局限性，但我不得不承認這是一篇很大氣的作品，其中涉及很多JSP的內(nèi)在原理。因此，我想還是有必要把這篇文章介紹給大家，以便各位從另一個側(cè)面更深入的了解JSP技術。）



　　如今每一個使用servlets的開發(fā)者都知道JSP，一種建構(gòu)在servlet技術之上的由Sun公司發(fā)明并花費大量精力加以推行的web技術。JSP將servlet中的html代碼脫離了出來，從而可以加速web應用開發(fā)和頁面維護。實際上，由Sun發(fā)布的官方 "應用開發(fā)模型"文檔上說得更遠："JSP技術應該被視為標準，而servlets在多數(shù)情況下可視為一種補充。"

　　本文將比較JSP和另一項基于servlets的技術：template engines（模板引擎）。

直接使用Servlets的問題
　　當Servlets被發(fā)明時，整個世界都看到了它的優(yōu)越性。基于Servlet的動態(tài)網(wǎng)頁可以被快速執(zhí)行，可以在多個服務器之間輕易轉(zhuǎn)移， 并且可以和后臺數(shù)據(jù)庫完美地集成，因此Servlets被廣泛接受成為一種web服務器端的首選平臺。

　　但是，通常通過簡單方式即可實現(xiàn)的html代碼現(xiàn)在卻要讓程序員通過 out.println()調(diào)用每一行HTML行，這在實際的 Servlet應用中變成一個嚴重問題。HTML內(nèi)容不得不通過代碼來實現(xiàn), 這對于大的HTML頁來說不啻是一項繁重費時的工作。另外，負責網(wǎng)頁內(nèi)容的人員不得不請開發(fā)人員來進行所有的更新。為此，人們尋求這一種更好的解決方式。

JSP誕生
　　JSP 0.90誕生了。在這種技術中你可以將Java代碼嵌入到HTML文件，服務器將自動為頁面創(chuàng)建一個Servlet。JSP被認為是一種寫Servlet的簡易方式。所有HTML可以直接得到而不必通過out.println()調(diào)用，而負責頁面內(nèi)容的人員可以直接修改HTML而不必冒破壞Java代碼的風險。

　　但是，讓頁面美術設計師和開發(fā)人員在同一文件上工作并不理想，讓Java嵌入HTML被證明是就象將HTML嵌入Java一樣令人尷尬。讀取一堆很亂的代碼仍然是一件困難的事情。

　　于是，人們在使用jsp方面變得成熟，更多地使用了JavaBeans。Beans包含了jsp所需的業(yè)務邏緝代碼。JSP中的大多數(shù)代碼都可以取出來放到bean中去，而只留下極少的標記用于調(diào)用bean。

　　最近，人們開始認為這種方式下的JSP頁面真的很象是視圖（view）。它們成為一個用于顯示客戶端請求結(jié)果的組件。于是人們會想，為什么不直接對view發(fā)送請求呢？目標view如果對該請求不合適又將如何？說到底，很多的請求有多種可能來取得結(jié)果view視圖。例如，同一請求可能產(chǎn)生成功的頁面、數(shù)據(jù)庫例外出錯報告，或者是缺少參數(shù)的出錯報告。同一請求可能產(chǎn)生一個英文頁面也可能是西班牙文頁面，這取決于客戶端的locale。為什么客戶端必須直接將請求發(fā)送給view？為什么客戶端不應該將請求發(fā)送給一些通用的服務器組件并讓服務器來決定JSP view的返回？

　　這使很多人接受了已被稱為"Model 2"的設計, 這是在JSP 0.92中定義的基于model-view-controller的模型。在這種設計中，請求被發(fā)送到一個servlet控制器，它執(zhí)行了商業(yè)邏緝并產(chǎn)生一個相近的數(shù)據(jù)"model"來用于顯示。這一數(shù)據(jù)隨后通過內(nèi)部送到一個JSP "view"來進行顯示，這樣看起來JSP頁就象是一個普通的嵌入的JavaBean�？梢愿鶕�(jù)負責控制的servlet的內(nèi)部邏輯來選擇適當?shù)腏SP頁面進行顯示。這樣，JSP文件成為了一個漂亮的template view。這就是另一種發(fā)展，并被另外一些開發(fā)者所推崇至今。

進入Template Engines
　　如果使用template engine來代替通常目的的JSP, 接下去的設計將變得簡單，語法更簡單，出錯信息更易讀，工具也更用戶化。一些公司已經(jīng)做了這樣的引擎，最著名的可能是WebMacro，他們的引擎是免費的。

　　開發(fā)者應該明了，選定一個template engine來取代JSP提供了以下一些技術優(yōu)勢，而這些同時也正是jsp的不足之處：

　　問題 #1: Java代碼太模板化了

　　雖然被認為是不好的設計，JSP仍試圖將Java代碼加入web頁面。這有些象是Java曾經(jīng)做過的事情，即對C++的簡化修改，template engines也通過將jsp中的較低層的源碼移去來使之簡化。而Template engines實行了更好的設計。

　　問題 #2: 要求寫Java代碼

　　在JSP頁中要求寫一些Java代碼。例如，假設某頁要決定當前web應用中根的上下文從而導向其主頁，在JSP中最好使用如下Java代碼：

　　Home page

　　你可以試圖避免Java代碼，而使用 標記，但這將給你如下難以閱讀的字符串：

　　/index.html">HomePage

　　使用template engine則沒有Java代碼和難看的語法。這里是同樣要求下在WebMacro中的寫法：

　　Home page

　　在WebMacro中, ContextPath 作為 $Request變量的一個屬性，使用類似Perl的語法。其它template engines使用了其它的語法類型。

　　再看另一個例子，假設一個高級的"view"需要設定一個cookie來記錄用戶缺省的顏色配置 -- 這種任務看起來大概只能由view而不是servlet控制器來完成。在JSP中要有這樣的Java代碼：

　　

　　在WebMacro中則沒有Java代碼：

　　#set $Cookie.colorscheme = "blue"

　　作為最后一個例子，假如又要重新找回原來的cookie中的顏色配置。對于JSP，我們可以認為也有一個相應的工具類來提供幫助，因為用getCookies()直接做這樣低層的會變得可笑而且困難。在JSP中：

　　

　　在WebMacro中沒有對工具類的需要，通常是：

　　$Cookie.colorscheme.Value

　　對于必須去寫jsp的圖形界面設計師，哪一種語法更容易學習呢？

　　JSP 1.1 引入了自定義標記（custom tags）允許任意的和HTML相似的標記在JSP頁面中在后臺執(zhí)行Java代碼，這將具有一定的價值，但前提是要有一個廣泛知曉的，全功能的，可以免費得到的，標準化的標記庫。目前還沒有出現(xiàn)這樣的標記庫。
問題 #3: 簡單工作仍然很累人

　　即使是很簡單的工作，例如包含 header和 footer，在JSP中仍然很困難。假設有一個"header"和一個"footer"模板要包含到所有頁面，而每一個模板要在content中包含當前的頁標題。

　　在JSP中最佳辦法是：

　　

　　

　　...你的頁面內(nèi)容...

　　

　　頁面設計者要記住不能遺漏第一行的分號并要將title定義為一個字符串。此外，/header.jsp和/footer.jsp必須在根目錄下并且必須是可存取的完整文件。

　　在WebMacro中包含headers和footers做起來比較簡單：

　　#set $title = "The Page Title"

　　#parse "header.wm"

　　Your content here

　　#parse "footer.wm"

　　這里對設計者來說沒有要牢記的分號或?qū)�title的定義，.wm文件可以放在可自定義的搜索路徑下。

　　問題 #4: 很粗燥的循環(huán)

　　在JSP中循環(huán)很困難。這里是用JSP重復打印出每一個ISP對象名字。

　　

　　也許什么時候會有用戶自定義標記來做這些循環(huán)。對"if"也是如此。JSP頁可能看上去成了很古怪的java代碼。而同時，webmacro循環(huán)很漂亮：

　　#foreach $isp in $isps {

　　The next name is $isp.Name


　　}

　　如果必要的話，#foreach指令可被自定義的 #foreach-backwards指令很容易地取代。

　　用jsp的話很可能變這樣：（這里是一個可能的 標記）

　　

　　The next name is


　　

　　設計者當然地會選擇前者。

　　問題 #5: 無用的出錯信息

　　JSP常有一些令人驚訝的出錯信息。這是因為頁面首先被轉(zhuǎn)換成為一個servlet然后才進行編譯。好的JSP 工具可以相對增加找到出錯位置的可能性，但即使是最好的工具也無法使所有出錯信息都能容易地被讀懂。由于轉(zhuǎn)化的過程，一些錯誤對工具來說可能根本不可能被識別。

　　例如，假設JSP頁面需要建立一個對所有頁通用的標題。以下代碼并沒有錯：

　　

　　但Tomcat會提供以下出錯信息：

　　work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Statement expected.

　　static int count = 0;

　　^

　　此信息認為以上腳本被放入 _jspService()方法而靜態(tài)變量不允許放入方法中。該語法應該是 。頁面設計者很難讀懂這些出錯信息。即使最好的平臺在這方面也做得很不夠。即使所有 Java代碼都從頁中移出也無法解決問題。另外，以下表達式有什么錯？

　　

　　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");

　　^

　　換句話說，其實只不過是遺失了一個標記而已。應該是 。

　　由于template engine可以在template文件中直接產(chǎn)生而沒有任何戲劇性的向代碼轉(zhuǎn)化，所以可以非常容易地給出適當?shù)某鲥e報告。依次類推，當c語言的命令被打入Unix shell的命令行，你并不希望shell會生成一個C程序來運行這個命令，而只是需要shell簡單地解釋命令并加以執(zhí)行，如有錯誤也直接給出。

　　問題 #6: 需要一個編譯器

　　JSP需要一個置放在webserver中的編譯器。由于Sun拒絕放棄包含了他們的javac編譯器的tools.jar庫， 這其中就變得有問題了。Web服務器可以包含進一個第三方的編譯器如ibm的jikes。但這樣的編譯器并不能在所有平臺上順利工作(用 C++寫成的) 也不利于建立純Java 的web服務器。JSP還有一個預編譯選項可以起到一定作用，但并不完美。

　　問題 #7: 空間的浪費

　　JSP消耗了額外的內(nèi)存和硬盤空間。對服務器上每30K的JSP文件，必須要有相應的大于30K的類文件產(chǎn)生。實際上使得硬盤空間加倍�？紤]到JSP文件隨時可以很容易地通過 <%@ include>包含一個大的數(shù)據(jù)文件，這樣的關注有著很現(xiàn)實的意義。同時，每一個JSP的類文件數(shù)據(jù)必須加載到服務器的內(nèi)存中，這意味著服務器的內(nèi)存必須永遠地將整個JSP文檔樹保存下去。少數(shù)一些JVM有能力將類文件數(shù)據(jù)從內(nèi)存中移去；但是，程序員通常無法控制這樣的規(guī)則來重新申明，而且對大的站點來說重新申明可能不是很有效。對template engines由于沒有產(chǎn)生第二個文件，所以節(jié)省了空間。Template engines還為程序員提供對templates在內(nèi)存中進行緩存的完全控制。

使用template engine也有一些問題
　　Template的問題 #1: 沒有嚴格定義

　　template engine該如何工作并沒有嚴格定義�？墒牵�但相對jsp來說，其實這并不很重要，和 JSP不同的是，template engines對web服務器沒有任何特殊要求 -- 任何支持servlet的服務器都可以支持template engines (包括API 2.0服務器如Apache/JServ，它們并不能完全支持 JSP)! 如果為最好的template engine設計提供健康的競爭本可以引起一場耀眼的革新，特別是有開放源碼的促進，（可以讓思想相互推動和促進），那么今天的WebMacro就會象Perl一樣，沒有嚴格定義但公開源碼組織的推動就是它的標準。

　　Template的問題 #2: 沒有獲得公認

　　Template engines并未被廣泛知曉。JSP已經(jīng)占據(jù)了極大的商業(yè)市場，并且深入人心。而使用g template engines只能是一種未被了解的替代技術。

　　Template的問題 #3: 尚未調(diào)配好

　　Template engines還沒有被高度地調(diào)配好。沒有對template engine 和JSP兩者進行性能測試和比較。理論上說一個調(diào)配完好的template engine實現(xiàn)應該和一個調(diào)配好的JSP相匹配；但是，考慮到第三方為jsp已經(jīng)作出了這么深遠的推動，結(jié)果只有jsp被很好地調(diào)配好了。

JSP的角色
　　當然，JSP必然會有其地位。即使從名稱上也可以看出JSP和ASP的相似性，它們只有一個字母的差別。所以如果要讓使用asp的人們轉(zhuǎn)向java,非常相似的jsp環(huán)境將對此起到很大的推動作用，和asp保持這種對應關系所能起到的作用應該也是被當時推出jsp的設計者重點考慮到的。

　　然而這里想要強調(diào)的一點是：有利于轉(zhuǎn)入新環(huán)境的工作者，和實際上是否使用了該環(huán)境的最佳方式，這兩者是有很大不同的。

　　JSP的發(fā)展已經(jīng)日益表明，它正成為最重要的java技術之一，它讓人們離開ASP的世界 -- 由此，Sun將支持這一強有力的商業(yè)case, Java相關技術支持者也將給予更大力的支持。

　　然而遺憾的是，其實這并非java平臺的最佳解決方案。這將使java解決方案變得好象是沒有java的解決方案了。