top
Loading...
我認為JSP有問題(下)
問題 #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("");

^

換句話說,其實只不過是遺失了一個標記而已。應該是 <%= 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的解決方案了。

北斗有巢氏 有巢氏北斗