隨筆分類(103)

    這里我們要將 Tapestry 與其它主要的 Java Web 框架做一番比較，包括 Struts，JSF。

    Struts 是一個 Action 方式的 Web 框架，所有的請求直接對應了相應的 Action，我們需要通過一些相應的技巧性處理才能把我們在頁面上的 Click，Value Change 等轉換到后端對應的 Action，抽象程度顯得不夠高，并且這樣會使 Struts 在處理一些較為復雜的頁面時配置過多，造成開發和維護上的繁雜。另外 Struts 默認使用的 Tiles 模板框架使用了 <jsp:include> 方式的拼裝頁面技術，并且在每個頁面都需要配置，這樣的話，又增加了不少的配置量。在Struts中，經常需要使用標簽庫通過 EL（Expression Language）來顯示組件ActionForm中內容，這就涉及到一個結合的問題，標簽庫是別人寫的，而且 Struts 在這方面并沒有確定的標準，如何才能讓自己的組件庫和現有的組件庫很好的結合，難度和麻煩就體現在這個結合點上。

    JSF的視圖層開發的基本思路和Struts差不多，只不過換了不同標簽庫，也需要標簽庫+組件的結合思考，不過因為組件這里是通用組件，沒有什么限制，并且遵循了一個共同的標準，所以這樣比Struts要輕松一些。JSF 提供了一套完整的生命周期和組件標準，我們很容易的為其定制一些組件和使用現有的組件庫。另外JSF采用了事件驅動的方式，同一個頁面對應的多個 Action 請求會比較直接的通過 EL映射到后端對應的 Java 方法上，從而大大減少了復雜頁面的配置量。但是在默認情況下，JSF 每個頁面的都需要配置其單獨的導航，如果頁面導航復雜的話，配置還是不少的。JSF 在默認情況下并沒有集成模板引擎，但是開源的 Facelets 模板引擎提供了類似 Tapestry 的模板方式，從另外一種方式簡化了 JSF 的開發。JSF 采用了 HTML 頁面保存組件樹的機制，頁面的所有組件和組件狀態被序列化到頁面中或者 Session 中，這樣的話，如果在頁面上 Javascrīpt 通過修改 DOM 的方式修改頁面的組件，會導致頁面和組件樹不一致，導致 JSF 無法正常工作，但是可以通過 Ajax 方式向服務端發出更新組件樹的請求，但這樣需要走完 JSF 整個生命周期，顯得較為笨重，所以從架構上來看，JSF 在處理頁面問題上不夠靈活，也不夠 Ajax 化。

    Tapestry使用了組件庫的概念替代了標簽庫，沒有標簽庫概念，這樣就沒有標簽庫和自己的組件需要結合的問題，都是組件的使用，組件中分Tapestry標準組件和自己定義的組件，這也是接觸了JSP體系的人學習Tapestry面臨的一個思路轉換。這樣極大的減小了頁面修改而帶來的修改難度。同為事件驅動的框架，在配置上 Tapestry 有著和 JSF 類似的優勢，我們只需要簡單的在 XML 文件里配置事件和后端方法的對應關系，或者使用 OGNL 直接在頁面中與后端方法建立關聯。在頁面導航上，Tapestry 是根據監聽器方法的返回值而確定，這樣就省去了頁面導航部分的配置。Tapestry 的模板技術天生就是其優勢所在，這樣的方式將前臺頁面的制作和后臺業務系統的開發完美的結合在一起。Tapestry 因為沒有 JSF 這樣的組件樹綁定的方式，就能夠比較容易的和 Ajax 綁定在一起，目前開源的 Tacos 組件庫就提供了很多這樣的組件，并且整合了 Dojo Toolkit 使得我們開發頁面中有了更多好用的組件，并且只需要很簡單的配置工作就可以使用功能強大的 Web 組件和 Ajax 功能。

    另外，JSF/Tapestry不只是支持HTML，也支持多種客戶端語言如WML或XUI等。