隨筆分類(103)

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

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

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

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

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