Cocoon原始動力

關於Cocoon，希望有一本《XSP/Cocoon/XML核心技術內幕》，基本上編譯了一些基本的Cocoon文檔，有一定的參考價值。這也是我看到的國內唯一的一本Cocoon的參考書。但是該書如同其它國內書籍一樣，對於基本理念的闡述不夠詳細和清晰。

Cocoon的原始動力是爲了實現Content-Style-Logic的三層分離，這是一個Web Engineer的很好的實踐。

Cocoon 也源自於以前的ServerPages技術（主要是針對JSP，當然ASP和PHP也有同樣的問題）的缺陷。儘管JSP提出了JSP Model 2，來實現Model-View-Controller分離，即用JavaBean表示數據（內容），用Servlet控制業務邏輯，用JSP實現顯示邏輯和表現層，但還是有些實踐上的缺陷。關於這個問題的描述，在2000年10月的文章《JSP 技術 -- 是友還是敵？》（http://www-900.ibm.com/developerWorks/cn/java/w-friend /index.shtml）中有詳盡的討論。

但是如果我們跟上技術發展的步伐，就會看到這個問題由於標籤庫技術的成熟和servlet過濾器機制的誕生而得到解決。TagLib早就有了，但是直到臨近JSTL即JSP Standard Tag Library的正式發佈，其威力才真正顯現。

從角色任務上看，程序員主要負責JavaBean、Servlet和編寫自定義標籤庫（現在可以使用JSTL從而大大減少負擔）；設計者編寫“不包含 java代碼”的JSP，實際上是若干種標記的混合，HTML+JSTL+自定義標籤。我認爲這種框架比較適合於以Java程序員爲主的團隊，以及業務邏輯複雜的應用。

注意，正如JSP的內嵌Java代碼可以實現業務邏輯，JSP的TagLib技術，一樣可以用於實現業務邏輯。當然使用 TagLib將比內嵌Java代碼好許多，因爲代碼被封裝到了TagLib中，因此對於小的應用還是可以使用JSP，而不用寫Servlet。例如使用 JSTL的sql tag，來直接處理數據庫（這實際上意味着基本沒有或者只有極其簡單的包含在sql語句中的業務邏輯）。也可以用像、之類的tag來處理業務邏輯，雖然通常應該只被用來處理顯示邏輯。固然，這些功能會“引誘”一些人過度使用TagLib的能力而破壞了設計原則，但對於原型開發、測試以及輕量級應用，實在是太有用了！如果是企業級應用，相信有能力做企業級應用的程序員，也會有足夠的意識來按照MVC模式開發。

Apache的Struts是一個基於JSP實現MVC的很好的框架，建議有興趣的同志研究研究。

而 Cocoon，用XML表示數據（內容），用XSP（非常類似JSP的XML形式）編寫業務邏輯，用XSLT實現表示層（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的 WebSphere），或者採用Cocoon。但是現在Servlet有非常強大的filter機制。這使得Cocoon與JSP越來越有結合的趨勢。

但Cocoon的特點在於，除了核心功能（Core-Cocoon）之外，它還包括內部組件（包括Matchers、Generators、Transformers、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數據和靈活的格式轉換需求的應用。