如今每一個使用servlets的開發(fā)者都知道JSP,一種由Sun公司發(fā)明并花費大量精力加以推行并建構(gòu)在servlet技術(shù)之上的web技術(shù)。JSP將servlet中的html代碼脫離了出來,從而可以加速web應(yīng)用開發(fā)和頁面維護。實際上,由Sun發(fā)布的官方"應(yīng)用開發(fā)模型"文檔上說得更遠: "JSP技術(shù)應(yīng)該被視為標準,而servlets在多數(shù)情況下可視為一種補充。" ( Section 1.9, 1999/12/15聽取意見版 )。
本文的目的在于聽取對該申明的合理性的評估 -- 通過比較JSP和另一項基于servlets的技術(shù): template engines(模板引擎)。
直接使用Servlets的問題
起初,servlets被發(fā)明,整個世界都看到了它的優(yōu)越;趕ervlet的動態(tài)網(wǎng)頁可以被快速執(zhí)行,可以在多個服務(wù)器之間輕易轉(zhuǎn)移, 并且可以和后臺數(shù)據(jù)庫完美地集成。 Servlets被廣泛接受成為一種web服務(wù)器端的首選平臺。
但是,通常通過簡單方式即可實現(xiàn)的html代碼現(xiàn)在卻要讓程序員通過 out.println()調(diào)用每一行HTML行,這在實際的 servlet應(yīng)用中成為了一個嚴重問題。 HTML內(nèi)容不得不通過代碼來實現(xiàn), 對于大的HTML頁來說不啻是一項繁重費時的工作。另外,負責(zé)網(wǎng)頁內(nèi)容的人員不得不請開發(fā)人員來進行所有的更新。為此,人們尋求這一種更好的解決方式。
JSP到!
JSP 0.90出現(xiàn)了。在這種技術(shù)中你可以將Java代碼嵌入到HTML文件,服務(wù)器將自動為頁面創(chuàng)建一個 servlet。 JSP被認為是一種寫servlet的簡易方式。所有HTML可以直接得到而不必通過out.println()調(diào)用,而負責(zé)頁面內(nèi)容的人員可以直接修改HTML而不必冒破壞Java代碼的風(fēng)險。
但是,讓頁面美術(shù)設(shè)計師和開發(fā)人員在同一文件上工作并不理想,讓Java嵌入HTML被證明是就象將HTML 嵌入Java一樣令人尷尬。讀取一堆很亂的代碼仍然是一件困難的事情。
于是,人們在使用jsp方面變得成熟,更多地使用了JavaBeans。 Beans包含了jsp所需的業(yè)務(wù)邏緝代碼。JSP中的大多數(shù)代碼都可以取出來放到bean中去,而只留下極少的標記用于調(diào)用bean。
近,人們開始認為這種方式下的JSP頁面真的很象是視圖(view)。它們成為一個用于顯示客戶端請求的結(jié)果的組件。于是人們會想,為什么不直接對view發(fā)送請求呢? 目標view如果對該請求不合適又將如何? 說到底,很多的請求有多種可能來取得結(jié)果view視圖。例如,同一請求可能產(chǎn)生成功的頁面,數(shù)據(jù)庫例外出錯報告,或者是缺少參數(shù)的出錯報告。同一請求可能產(chǎn)生一個英文頁面也可能是西班牙文頁面,這取決于客戶端的locale。為什么客戶端必須直接將請求發(fā)送給view?為什么客戶端不應(yīng)該將請求發(fā)送給一些通用的服務(wù)器組件并讓服務(wù)器來決定JSP view的返回?
這使很多人接受了已被稱為"Model 2"的設(shè)計, 這是在JSP 0.92中定義的基于model-view-controller的模型。在這種設(shè)計中,請求被發(fā)送到一個servlet控制器,它執(zhí)行了商業(yè)邏緝并產(chǎn)生一個相近的數(shù)據(jù)"model"來用于顯示。這一數(shù)據(jù)隨后通過內(nèi)部送到一個JSP "view"來進行顯示,這樣看起來JSP頁就象是一個普通的嵌入的JavaBean。 可以根據(jù)負責(zé)控制的servlet的內(nèi)部邏輯來選擇適當(dāng)?shù)腏SP頁面進行顯示。這樣,JSP文件成為了一個漂亮的template view。這就是另一種發(fā)展,并被另外一些開發(fā)者所推崇至今.
進入Template Engines
使用template engine來代替通常目的的JSP, 接下去的設(shè)計將變得簡單,語法更簡單,出錯信息更易讀,工具也更用戶化。 一些公司已經(jīng)做了這樣的引擎,著名的可能是WebMacro (http://webmacro.org, from Semiotek),他們的引擎是免費的。
開發(fā)者應(yīng)該明了,選定一個template engine來取代JSP提供了這么一些技術(shù)優(yōu)勢,這也正是jsp的一些不足之處:
問題 #1: Java代碼太模板化了
雖然被認為是不好的設(shè)計,JSP仍試圖將Java代碼加入web頁面。這有些象是Java曾經(jīng)做的,即對C++的簡化修改,template engines也通過將jsp中的較低層的源碼移去來使之簡化。Template engines實行了更好的設(shè)計。
問題 #2: 要求Java代碼
在JSP頁中要求寫一些Java代碼。例如,假設(shè)某頁要決定當(dāng)前web應(yīng)用中根的上下文從而導(dǎo)向其主頁,
在JSP中好使用如下Java代碼:
<a href="<%= request.getContextPath() %>/index.html">Home page</a>
你可以試圖避免 Java代碼,而使用 <jsp:getProperty> 標記但這將給你六下難以閱讀的字串:
。糰 href="<jsp:getProperty name="request"
property="contextPath"/>/index.html">HomePage</a>
使用template engine則沒有Java代碼和難看的語法。這里是同樣要求下在WebMacro中的寫法:
。糰 href=".ContextPath;/index.html">Home page</a>
在WebMacro中, ContextPath 作為 template engines使用了其它的語法類型。
再看另 一個例子,假設(shè)一個高級的"view"需要設(shè)定一個cookie來記錄用戶缺省的顏色配置 -- 這種任務(wù)看起來大概只能由view而不是servlet控制器來完成。在JSP中要有這樣的Java代碼:
。% Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c); %>
在WebMacro中則沒有Java代碼:
#set .colorscheme = "blue"
作為后一個離子,假如又要重新找回原來的cookie中的顏色配置。對于JSP,我們可以認為也有一個相應(yīng)的工具類來提供幫助,因為用getCookies()直接做這樣低層的會變得可笑而且困難。在JSP中:
。% String colorscheme = ServletUtils.getCookie(request, "colorscheme"); %>
在WebMacro中沒有對工具類的需要,通常是:.colorscheme.Value .對寫jsp的圖形藝術(shù)師,又是哪一種語法更容易學(xué)習(xí)呢?
JSP 1.1 引入了自定義標記(custom tags)允許任意的和HTML相似的標記在JSP頁面中在后臺執(zhí)行Java代碼,這將具有一定的價值,但前提是要有一個廣泛知曉的,全功能的,可以免費得到的,標準化的標記庫。目前還沒有出現(xiàn)這樣的標記庫。
問題 #3: 簡單工作仍然很累人
即使是很簡單的工作,例如包含 header和 footer,在JSP中仍然很很困難。 假設(shè)有一個 "header"和一個 "footer"模板要包含到所有頁面,而每一個模板要在content中包含當(dāng)前的頁標題。
在JSP中佳辦法是:
。% String title = "The Page Title"; %>
。%@ include file="/header.jsp" %>
...你的頁面內(nèi)容...
。%@ include file="/footer.jsp" %>
頁面設(shè)計者要記住不能遺漏第一行的分號并要將title定義為一個字符串。此外, /header.jsp和/footer.jsp必須在根目錄下并且必須是可存取的完整文件。
在WebMacro中包含headers和footers做起來比較簡單:
#set 24 = "The Page Title"
#parse "header.wm"
Your content here
#parse "footer.wm"
這里對設(shè)計者來說沒有要牢記的分號或?qū)itle的定義, .wm文件可以放在可自定義的搜索路徑下。