困擾JSP的一些問題與處理方法

　　如今每一個(gè)使用servlets的開發(fā)者都知道JSP，一種由Sun公司發(fā)明并花費(fèi)大量精力加以推行并建構(gòu)在servlet技術(shù)之上的web技術(shù)。JSP將servlet中的html代碼脫離了出來，從而可以加速web應(yīng)用開發(fā)和頁面維護(hù)。實(shí)際上，由Sun發(fā)布的官方"應(yīng)用開發(fā)模型"文檔上說得更遠(yuǎn)： "JSP技術(shù)應(yīng)該被視為標(biāo)準(zhǔn)，而servlets在多數(shù)情況下可視為一種補(bǔ)充。" ( Section 1.9, 1999/12/15聽取意見版 )。

　　本文的目的在于聽取對(duì)該申明的合理性的評(píng)估 -- 通過比較JSP和另一項(xiàng)基于servlets的技術(shù)： template engines（模板引擎）。

　　直接使用Servlets的問題

　　起初，servlets被發(fā)明，整個(gè)世界都看到了它的優(yōu)越�；�于servlet的動(dòng)態(tài)網(wǎng)頁可以被快速執(zhí)行，可以在多個(gè)服務(wù)器之間輕易轉(zhuǎn)移， 并且可以和后臺(tái)數(shù)據(jù)庫完美地集成。 Servlets被廣泛接受成為一種web服務(wù)器端的首選平臺(tái)。
但是，通常通過簡(jiǎn)單方式即可實(shí)現(xiàn)的html代碼現(xiàn)在卻要讓程序員通過 out.println()調(diào)用每一行HTML行，這在實(shí)際的 servlet應(yīng)用中成為了一個(gè)嚴(yán)重問題。 HTML內(nèi)容不得不通過代碼來實(shí)現(xiàn), 對(duì)于大的HTML頁來說不啻是一項(xiàng)繁重費(fèi)時(shí)的工作。另外，負(fù)責(zé)網(wǎng)頁內(nèi)容的人員不得不請(qǐng)開發(fā)人員來進(jìn)行所有的更新。為此，人們尋求這一種更好的解決方式。

　　JSP到！

　　JSP 0.90出現(xiàn)了。在這種技術(shù)中你可以將Java代碼嵌入到HTML文件，服務(wù)器將自動(dòng)為頁面創(chuàng)建一個(gè) servlet。 JSP被認(rèn)為是一種寫servlet的簡(jiǎn)易方式。所有HTML可以直接得到而不必通過out.println()調(diào)用，而負(fù)責(zé)頁面內(nèi)容的人員可以直接修改HTML而不必冒破壞Java代碼的風(fēng)險(xiǎn)。
　　但是，讓頁面美術(shù)設(shè)計(jì)師和開發(fā)人員在同一文件上工作并不理想，讓Java嵌入HTML被證明是就象將HTML 嵌入Java一樣令人尷尬。讀取一堆很亂的代碼仍然是一件困難的事情。

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

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

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

　　進(jìn)入Template Engines

　　使用template engine來代替通常目的的JSP, 接下去的設(shè)計(jì)將變得簡(jiǎn)單，語法更簡(jiǎn)單，出錯(cuò)信息更易讀，工具也更用戶化。 一些公司已經(jīng)做了這樣的引擎，最著名的可能是WebMacro (http://webmacro.org, from Semiotek)，他們的引擎是免費(fèi)的。
　　開發(fā)者應(yīng)該明了，選定一個(gè)template engine來取代JSP提供了這么一些技術(shù)優(yōu)勢(shì)，這也正是jsp的一些不足之處：

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

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

　　問題 #2: 要求Java代碼

　　在JSP頁中要求寫一些Java代碼。例如，假設(shè)某頁要決定當(dāng)前web應(yīng)用中根的上下文從而導(dǎo)向其主頁，
在JSP中最好使用如下Java代碼：

　�。糰 href="＜%= request.getContextPath() %＞/index.html"＞Home page＜/a＞
　
　　你可以試圖避免 Java代碼，而使用 ＜jsp:getProperty＞ 標(biāo)記但這將給你六下難以閱讀的字串：

　�。糰 href="＜jsp:getProperty name="request"
　　property="contextPath"/＞/index.html"＞HomePage＜/a＞

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

　�。糰 href="$Request.ContextPath;/index.html"＞Home page＜/a＞

　　在WebMacro中, ContextPath 作為 $Request變量的一個(gè)屬性，使用類似Perl的語法。其它er template engines使用了其它的語法類型。
　　
　　再看另 一個(gè)例子，假設(shè)一個(gè)高級(jí)的"view"需要設(shè)定一個(gè)cookie來記錄用戶缺省的顏色配置 -- 這種任務(wù)看起來大概只能由view而不是servlet控制器來完成。在JSP中要有這樣的Java代碼：

　�。�% Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c); %＞

　　在WebMacro中則沒有Java代碼：

　　#set $Cookie.colorscheme = "blue"

　　作為最后一個(gè)離子，假如又要重新找回原來的cookie中的顏色配置。對(duì)于JSP，我們可以認(rèn)為也有一個(gè)相應(yīng)的工具類來提供幫助，因?yàn)橛胓etCookies()直接做這樣低層的會(huì)變得可笑而且困難。在JSP中：

　�。�% String colorscheme = ServletUtils.getCookie(request, "colorscheme"); %＞

　　在WebMacro中沒有對(duì)工具類的需要，通常是：$Cookie.colorscheme.Value ．對(duì)寫jsp的圖形藝術(shù)師，又是哪一種語法更容易學(xué)習(xí)呢？

　　JSP 1.1 引入了自定義標(biāo)記（custom tags）允許任意的和HTML相似的標(biāo)記在JSP頁面中在后臺(tái)執(zhí)行Java代碼，這將具有一定的價(jià)值，但前提是要有一個(gè)廣泛知曉的，全功能的，可以免費(fèi)得到的，標(biāo)準(zhǔn)化的標(biāo)記庫。目前還沒有出現(xiàn)這樣的標(biāo)記庫。

　　問題 #3: 簡(jiǎn)單工作仍然很累人

　　即使是很簡(jiǎn)單的工作，例如包含 header和 footer，在JSP中仍然很很困難。 假設(shè)有一個(gè) "header"和一個(gè) "footer"模板要包含到所有頁面，而每一個(gè)模板要在content中包含當(dāng)前的頁標(biāo)題。
在JSP中最佳辦法是：
　　＜% String title = "The Page Title"; %＞
　�。�%@ include file="/header.jsp" %＞
　　...你的頁面內(nèi)容...
　�。�%@ include file="/footer.jsp" %＞

　　頁面設(shè)計(jì)者要記住不能遺漏第一行的分號(hào)并要將title定義為一個(gè)字符串。此外， /header.jsp和/footer.jsp必須在根目錄下并且必須是可存取的完整文件。
　　在WebMacro中包含headers和footers做起來比較簡(jiǎn)單：

　　#set $title = "The Page Title"
　　#parse "header.wm"
　　Your content here
　　#parse "footer.wm"

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

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

　　在JSP中循環(huán)很困難。這里是用JSP重復(fù)打印出每一個(gè)ISP對(duì)象名字。
　　＜%
　　Enumeration e = list.elements();
　　while (e.hasMoreElements()) {
　　out.print("The next name is ");
　　out.println(((ISP)e.nextElement()).getName());
　　out.print("＜br＞");
　　}
　　%＞

　　也許什么時(shí)候會(huì)有用戶自定義標(biāo)記來做這些循環(huán)。對(duì)"if"也是如此。JSP頁可能看上去成了很古怪的java代碼。而同時(shí)，webmacro循環(huán)很漂亮：
　　#foreach $isp in $isps {
　　The next name is $isp.Name ＜br＞
　　}

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

　　用jsp的話很可能變這樣：（這里是一個(gè)可能的 ＜foreach＞標(biāo)記）

　�。糵oreach item="isp" list="isps"＞
　　The next name is ＜jsp:getProperty name="isp" property="name"/＞ ＜br＞
　�。�/foreach＞

　　設(shè)計(jì)者當(dāng)然地回選擇前者。
　　問題 #5: 無用的出錯(cuò)信息

　　JSP常有一些令人驚訝的出錯(cuò)信息。這是因?yàn)轫撁媸紫缺晦D(zhuǎn)換成為一個(gè)servlet然后才進(jìn)行編譯。好的JSP 工具可以相對(duì)增加找到出錯(cuò)位置的可能性，但即使是最好的工具也無法使所有出錯(cuò)信息都能容易地被讀懂。由于轉(zhuǎn)化的過程，一些錯(cuò)誤對(duì)工具來說可能根本不可能被識(shí)別。
例如，假設(shè)JSP頁面需要建立一個(gè)對(duì)所有頁通用的標(biāo)題。以下代碼并沒有錯(cuò)：

　　＜% static String title = "Global title"; %＞

　　但Tomcat會(huì)提供以下出錯(cuò)信息：
　　work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Statement expected.
　　static int count = 0;
　　^

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

　�。�% 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");
　　^

　　換句話說，只是遺失了一個(gè)標(biāo)記而已。應(yīng)該是 ＜%= count %＞。

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

　　問題 #6: 需要一個(gè)編譯器

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

　　問題 #7: 空間的浪費(fèi)

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

　　使用template engine也有一些問題：

　　Template的問題 #1: 沒有嚴(yán)格定義

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

　　Template的問題 #2: 沒有獲得公認(rèn)

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

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

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

　　JSP的角色

　　當(dāng)然地，JSP在將來必然會(huì)有其地位。即使從名稱上也可以看出JSP和ASP的相似性，它們只有一個(gè)字母的差別。所以如果要讓使用asp的人們轉(zhuǎn)向java,非常相似的jsp環(huán)境將對(duì)此起到很大的推動(dòng)作用，和asp保持這種對(duì)應(yīng)關(guān)系所能起到的作用應(yīng)該也是被推出jsp的設(shè)計(jì)者重點(diǎn)考慮到的。
然而這里想要強(qiáng)調(diào)的一點(diǎn)是：有利于轉(zhuǎn)入新環(huán)境的工作者，以及實(shí)際上是否是使用該環(huán)境的最佳方式，這兩者是有很大不同的。

　　JSP日益顯示出它正成為最重要的java技術(shù)之一， 它讓人們離開ASP的世界 -- 由此，Sun將支持這一強(qiáng)有力的商業(yè)case, Java相關(guān)技術(shù)支持者也將給予更大力的支持。

　　可是，這并非java平臺(tái)的最佳解決方案。這將使java解決方案變得好象是沒有java的解決方案了。