我認為JSP有問題（下）

js|問題 我認為JSP有問題（下）
（作者：小龍亭主Blueski編譯　2000年12月22日 14:22）

　　（續上篇）

　　問題 #3: 簡單工作仍然很累人

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

　　在JSP中最佳辦法是：

　　<% String title = "The Page Title"; %>

　　<%@ include file="/header.jsp" %>

　　...你的頁面內容...

　　<%@ include file="/footer.jsp" %>

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

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

　　#set $title = "The Page Title"

　　#parse "header.wm"

　　Your content here

　　#parse "footer.wm"

　　這裡對設計者來說沒有要牢記的分號或對title的定義，.wm檔案可以放在可自訂的搜尋路徑下。

　　問題 #4: 很粗燥的迴圈

　　在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頁可能看上去成了很古怪的java代碼。而同時，webmacro迴圈很漂亮：

　　#foreach $isp in $isps {

　　The next name is $isp.Name <br>

　　}

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

　　用jsp的話很可能變這樣：（這裡是一個可能的 <foreach>標記）

　　<foreach item="isp" list="isps">

　　The next name is <jsp:getProperty name="isp" property="name"/> <br>

　　</foreach>

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

　　問題 #5: 無用的出錯資訊

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

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

　　<% static String title = "Global title"; %>

　　但Tomcat會提供以下出錯資訊：

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

　　static int count = 0;

　　^

　　此資訊認為以上指令碼被放入 _jspService()方法而靜態變數不允許放入方法中。該文法應該是 <%! %>。頁面設計者很難讀懂這些出錯資訊。即使最好的平台在這方面也做得很不夠。即使所有 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檔案中直接產生而沒有任何戲劇性的向代碼轉化，所以可以非常容易地給出適當的出錯報告。依次類推，當c語言的命令被打入Unix shell的命令列，你並不希望shell會產生一個C程式來運行這個命令，而只是需要shell簡單地解釋命令並加以執行，如有錯誤也直接給出。

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

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

　　問題 #7: 空間的浪費

　　JSP消耗了額外的記憶體和硬碟空間。對伺服器上每30K的JSP檔案，必須要有相應的大於30K的類檔案產生。實際上使得硬碟空間加倍。考慮到JSP檔案隨時可以很容易地通過 <%@ include>包含一個大的資料檔案，這樣的關注有著很現實的意義。同時，每一個JSP的類檔案資料必須載入到伺服器的記憶體中，這意味著伺服器的記憶體必須永遠地將整個JSP文檔樹儲存下去。少數一些JVM有能力將類檔案資料從記憶體中移去；但是，程式員通常無法控制這樣的規則來重新申明，而且對大的網站來說重新申明可能不是很有效。對template engines由於沒有產生第二個檔案，所以節省了空間。Template engines還為程式員提供對templates在記憶體中進行緩衝的完全控制。

使用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已經佔據了極大的商業市場，並且深入人心。而使用g template engines只能是一種未被瞭解的替代技術。

　　Template的問題 #3: 尚未調配好

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

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

　　然而這裡想要強調的一點是：有利於轉入新環境的工作者，和實際上是否使用了該環境的最佳方式，這兩者是有很大不同的。

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

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

　　<全文完>