其實，jsf和tapestry也并不是那種頭碰頭的相同競爭性技術，兩者還是各有側重點的，不過比較細微，但是這種細微點在實現一個大工程時可能帶來不同的感受和變化。

　　首先，我們從一個高度來抽象一下表現層框架應有的技術架構，下圖可以說所有表現層框架技術都必須實現的功能架構圖：

　　當然，我們不必廢話羅嗦mvc模式，mvc模式是基準模式，現在框架技術已經不必再拼是否是mvc模式了。 在上圖mvc模式基礎上，一個表現層框架無外乎要實現圖中的三個功能：

　　1.在當前頁面能夠顯示一個組件對象的內容；而不是象純jsp那樣，需要在jsp頁面寫入“調用對象方法”的java代碼。

　　2.當用戶按下頁面的提交按扭或鏈接后，事件發生，這時應該觸發服務器端并將當前頁面的參數提交給服務器。這種機制表現在form表單提交和有參數的鏈接<a href=""></a>

　　3.從一個頁面視圖直接跳轉到另外一個頁面視圖，單純的導航作用。

　　我們通過下表來比較這 三種框架在實現上圖各個功能時技術細節，從而得出他們的異同點和偏重點。

　　struts組件編程模型

　　struts實現組件編程時有一些復雜：經常為一個頁面中需要引入多個組件而頭疼，因為struts中無法直接引入多個組件，必須繞一些圈子:

　　一般分兩種情況：如果同一個action就可以對付這些組件，那么在這種情況下有兩個辦法：

　　1.將這多個組件裝入一個actionform中，如使用mapform等機制；

　　2.手工將多個組件裝入request/session等scope中，然后根據其名稱在jsp中獲得。

　　這兩個方法都有缺點： 第一種辦法經常一個actionform弄得面目全非，變成一個大雜燴，違反了oo分派封裝的原則；第2種辦法其實又回到jsp編程；

　　第二種情況，如果這些組件必須有預先由不同的action來處理，每個組件必須經過action -->actionform流程，在這種情況下有兩種辦法：

　　1.使用tiles, 不同流程輸出到同一個頁面的不同區域。是一種并行處理方式。

　　2. 對多個流程首尾相連，第一action forward結果是第二個action，最后輸出一個jsp，在這個jsp中就可以使用前面多個流程的多個actionform了，這屬于串行方式。

　　struts組件模型缺點

　　struts組件編程必須限定在action/actionform/jsp這三個框框中做文章，難度相對比較大，而tapestry/jsf則沒有太多這些技術框框限制，兩者在組件編程方面更讓編程者自由一些，方便一些，這也是組件型框架的優勢吧。

　　struts標簽庫

　　在struts中，經常需要使用標簽庫來顯示組件actionform中內容，這就涉及到一個結合的問題，標簽庫是別人寫的，參考struts的標簽庫用法，而組件是自己的，難度和麻煩就體現在這個結合點上。

　　jsf基本思路和struts差不多，只不過換了不同標簽庫，也需要標簽庫+組件的結合思考，不過因為組件這里是通用組件，沒有什么限制，所以這樣比struts要輕松一些。

　　tapestry使用了組件庫概念替代了標簽庫，沒有標簽庫概念，這樣就沒有標簽庫和自己的組件需要結合的問題，都是組件的使用，組件中分tapestry標準組件和自己定義的組件，這也是接觸了jsp體系的人學習tapestry面臨的一個思路轉換。

　　具體以頁面跳轉為例子，頁面跳轉是靠鏈接<a href="目標"></a> 實現，鏈接是頁面經常使用的元素。

　　struts提供的html:link在頻繁使用就特別不方便，尤其在傳遞多個參數時：其中html:link的page值，是跳轉對方頁面或action的path，這個path一般需要到struts-config.xml查找action的相應path,一旦配置文件path值修改，涉及到這個所有相關頁面都要修改。

　　jsf將鏈接概念劃分兩個方面：導航性質和事件激活，在導航方面還是需要到配置faces-config查詢navigation的from-outcome的值。

　　由于tapestry沒有標簽庫概念，只有組件或頁面兩個概念，因此，鏈接跳轉目標要么是組件，要么是頁面，簡潔簡單，它沒有多余的path概念，就是組件名，也就是對象名稱，組件名稱和path名稱合二為一。

　　總結

　　jsf在很大程度上類似struts，而不是類似tapestry，可以說是一種struts 2.0，都是采取標簽庫+組件的形式，只是jsf的組件概念沒有象struts那樣必須繼承actionform的限制；jsf在事件粒度上要細膩，不象struts那樣，一個表單一個事件，jsf可以細化到表單中的每個字段上。

　　jsf只有在組件和事件機制這個概念上類似tapestry，但是不似tapestry那樣是一個完全組件的框架，所以，如果你做一個對頁面要求靈活度相當高的系統，選用tapestry是第一考慮。

　　struts/jsf則適合在一般的數據頁面錄入的系統中，對于struts和jsf的選用，我目前個人觀點是：如果你是一個新的系統，可以直接從jsf開始；如果你已經使用struts，不必轉換，如果需要切換，可以將jsf和tapestry一起考慮。

　　另外，jsf/tapestry不只是支持html，也支持多種客戶端語言如wml或xui等。

　　這三者之間關系：如果說struts是左派；那tapestry則是右派；而jsf則是中間派，中庸主義是sun聯盟的一貫策略。

　　當然，你也可以發表你在實踐中這三者任何一個的使用感受，以使得后來者有一個比較。