再談Cocoon兼談JSP (轉)

再談Cocoon兼談JSP (轉)[@more@]

一年前的舊文，今天看來仍有其價值。

 

發信人: (海曦), 信區: Develop 標 題: 再談Cocoon兼談 發信站: 飲水思源 (2002年06月06日01:17:17 星期四), 站內信件 著名的 IBM DW 中文網站，推出了Cocoon 2的簡介教程，從而再次把我們的目光吸引到Cocoon上。以下是我在CSDN的討論區發表的個人看法，貼過來漲點人氣。 IBM的這個教程非常好，強烈推薦。BTW，IBM的DW網站比CSDN有用多了。 關於Cocoon，希望有一本《XSP/Cocoon/XML核心技術內幕》，基本上編譯了一些基本的Cocoon文件，有一定的參考價值。這也是我看到的國內唯一的一本Cocoon的參考書。但是該書如同其它國內書籍一樣，對於基本理念的闡述不夠詳細和清晰。 Cocoon的原始動力是為了實現Content-Style-Logic的三層分離，這是一個Web Engineer的很好的實踐。 Cocoon也源自於以前的ServerPages技術（主要是針對JSP，當然和 也有同樣的問題）的缺陷。儘管JSP提出了JSP Model 2，來實現 Model-View-Controller分離，即用Bean表示資料（內容），用 控制業務邏輯，用JSP實現顯示邏輯和表現層，但還是有些實踐上的缺陷。關於這個問題的描述，在2000年10月的文章《JSP 技術 - - 是友還是敵？》（http://www-900.ibm.com/developerWorks/cn/ java/w-friend/index.shtml）中有詳盡的討論。 但是如果我們跟上技術發展的步伐，就會看到這個問題由於標籤庫技術的成熟和servlet過濾器機制的誕生而得到解決。早就有了，但是直到臨近即JSP Standard Tag Library的正式釋出，其威力才真正顯現。 從角色任務上看，員主要負責JavaBean、Servlet和編寫自定義標籤庫（現在可以使用JSTL從而大大減少負擔）；設計者編寫“不包含 java程式碼”的JSP，實際上是若干種標記的混合，HTML+JSTL+自定義標籤。我認為這種比較適合於以Java程式設計師為主的團隊，以及業務邏輯複雜的應用。 注意，正如JSP的內嵌Java程式碼可以實現業務邏輯，JSP的TagLib技術，一樣可以用於實現業務邏輯。當然使用TagLib將比內嵌Java程式碼好許多，因為程式碼被封裝到了TagLib中，因此對於小的應用還是可以使用JSP，而不用寫Servlet。例如使用JSTL的 tag，來直接處理資料庫（這實際上意味著基本沒有或者只有極其簡單的包含在sql語句中的業務邏輯）。也可以用像、之類的tag來處理業務邏輯，雖然通常應該只被用來處理顯示邏輯。固然，這些功能會“引誘”一些人過度使用TagLib的能力而破壞了設計原則，但對於原型開發、測試以及輕量級應用，實在是太有用了！如果是企業級應用，相信有能力做企業級應用的程式設計師，也會有足夠的意識來按照MVC開發。 的是一個基於JSP實現MVC的很好的框架，建議有興趣的同志研究研究。 而Cocoon，用XML表示資料（內容），用XSP（非常類似JSP的XML形式）編寫業務邏輯，用T實現表示層（HTML、WML、某種格式的XML甚至PDF），並用sitemap（Cocoon 2）集中管理。XSP邏輯單則與JSP的 TagLib從概念到用法非常相似，只是實現方法略有不同。JSP的TagLib 包括一個xml格式的定義和實現的Tag類，並被編譯使用；而XSP 邏輯單則在執行時（當然可以進行Cache）應用XSLT進行從標記到程式碼的轉換。 （按照我對IBM教程的理解）事實上按照管道的概念，從原始資料到最終呈現可以有任意層，至於如何分層，每個層的用途，則在於設計者。這也是為什麼Cocoon被定位於Web釋出“框架”。 一個處理流程可以被描述為：（摘自IBM教程）從接受請求。確定用來解釋該請求並生成響應的適當管道（使用匹配器）。從可用的預的構造管道。指示管道為請求服務。將由管道生成的響應返回使用者，可能對結果進行快取記憶體以便以後使用。 在JSP Model 2裡，Servlet扮演“排程員”的角色，我們用它來控制任務分派，這有點類似管道所作的事情。事實上，Cocoon就是一個大 Servlet。只是Servlet在2.3之前缺乏管道機制，只能進行簡單的 forward和include，如果需要多重處理機制，就不得不依靠擴充套件庫（比如IBM的），或者採用Cocoon。但是現在Servlet有非常強大的filter機制。這使得Cocoon與JSP越來越有結合的趨勢。 但Cocoon的特點在於，除了核心功能（Core-Cocoon）之外，它還包括內部元件（包括Matchers、Generators、Tranormers、Serializer s、Aggregators等）、內部邏輯單（Response、Sitemap、XSP、XSP- Request、Util、XSP-Cookie、Log等）。這樣它就有一個非常適合Web 釋出的環境。而使用JSP，相對來說，需要自己進行配置和寫部分的基礎程式碼。 從角色任務上看，站點管理員負責定義Sitemap，程式設計師主要負責XSP 邏輯單，設計者編寫XSLT樣式表（包括XSLT和目的碼如HTML），因為程式設計師和設計者都使用XSLT，其實就是在寫格式轉換，只是編寫者需要熟悉如何處理輸入和輸出（如設計者要面對HTML，程式設計師要考慮 ）。此外，在此之前需要有額外的角色來定義所用到的XML或其他中間格式。我認為這種框架比較適合於非Java程式設計師為主的團隊，管理員只要熟悉XML，程式設計師和設計者需要掌握XSLT；以及適合於業務邏輯相對簡單，而著重於xml資料和靈活的格式轉換需求的應用。 -- ※ 來源:·飲水思源 bbs.sjtu.edu.cn·[FROM: 202.120.15.34]