我的目在JSF和AJAX的整合。不管你選擇什麼版本的JSF，與AJAX的整合對於構建企業級應用程序來說是一個不錯的選擇。我會給大家展示這兩種技術結合的方法，我特意增加了一些新內容——因為在這之前，已經有了JSF和AJAX的實際測試方法，但這種測試方法出現並不只局限於與JSF整合的AJAX應用，任何AJAX應用程序都可以使用．最後，我還會陳述一下如何評價JSF和AJAX的解決方案． 現在，我發現JSF與最初的2001年所處的情況驚人的相似——那個時就已經有許許多多的web框架，真可謂是百家爭鳴，而JSF在其中脫穎而出，以絕對優勢成為JCP標准．但現在，這種局面再次出現了．在過去的六年，我們始終緊跟時代的步伐，但仍然還有大量的web框架鏖戰在我們周圍，但是根據從采用JSF技術的網站數據以及供應商為之提供的工具和組件數量來看，JSF還是在不斷增長且在市場上仍有一席之地，因此許多供應商也相繼推出了JSF和AJAX整合方案．在今天下午2:30的小組討論中，我和來自ICEsoft的Steve Maryka會一同出席，大家也許已經知道Steve已經推出一套相當漂亮的JSF和AJax整合方案．屆時我會以Sun代表身份出現，當然除Steve外，還有很多知名人士，我會將他們的姓名列在幻燈片上．但不管怎樣，我只想給你們提供一些信息，以便當你看完這些不同的解決方案後，扪心自問：哪一個方案是最佳的？它有什麼特性？這些特性可以滿足我的企業要求嗎？
“企業級”已經是一個被過度濫用的術語了．那麼按照我自己的理解，企業級指的是健壯，可伸縮，易於測試以及被業界證明可用性(industry proven)等．它需要被開發人員證明切實可行！JSF滿足上述要求，因為剛才我所講的大量的站點和大量的供應商支持足以證明這一點．另一個關於“企業級”的說法是：易於使用，易於開發，當然也包括易於測試．TDD（測試驅動開發）我的確喜歡，當我在領導團隊開發一個JSF實現時，我們所做的一切都采用了TDD，並且效果顯著．當然，“企業級的工具”也需要同時能夠滿足開發人員的需求．這一切往往在職場上扮演重要角色：你會雇用什麼樣的人才？他們所掌握的技能能夠勝任這個開發工具嗎？現存的開發工具是否又能滿足他們的要求呢？並且最後一點我要強調的是：良好的可擴展性觀念．當你所遇到的問題越來越多時，你所依賴的解決方案也要不斷的提供抽象來解決這些不斷增長的問題，此時JSF作為一個基於組件和多個擴展的解決方案，支持抽象和組件化滿足了可擴展性．這就是我所定義的“企業級”概念．
那麼我所指的AJAX，也在這裡告訴給大家吧：web應用程序通過使用異步機制與服務端進行交互，並且動態更新浏覽器所顯示頁面的外觀和行為．這麼來定義AJAX我覺得還是有稍稍有點生硬．如果你與ICEsoft接觸過，你會發現他們已經有了AJAX的“推”模式，使用了大量技術可以異步的將內容通過浏覽器發送出去．大家熟知的Comet就是這種編程模式的一種實踐，它在與AJAX整合時非常有用，不過今天我沒有在幻燈片上提供任何關於它的信息，但是可以很明確地的說：Comet就是為與AJax整合，當然也包括與JSF的整合．
好了，說完了的目的後，正式開始我們今天的議程吧．為什麼JSF要與AJAX整合？為什麼我會強調AJAX對於web應用程序來說是必須的？JSF和AJAX的整合方法有很多．其中JSF本身的設計和特性就使得它適合協同AJax進行開發．下面是我們調查到的一些問題和解決方案．
一個解決這些問題的方案來自於Project Dynamic Faces（JSF的一個AJAX擴展）和MCP（Mozilla Control Program，使用JUnit或TestNG來自動測試web應用程序的一個包）．這是一個很早就有的解決方案，當時我還在www.mozilla.org工作時已經有些Alpha級的技術來自動測試AJax程序．現在我手頭上有一些關於它的demo。
所有的web應用程序必須經過下列過程．為確保萬無一失(motherhood applepIE：美國黑話或政治家慣用的說語)，你需要進行數據轉換和數據驗證，需要一種機制來指定頁面流程(page flow)，需要整合數據庫．當然，你也許還會用持久層技術，比直接就可用的JAP和Hiberante．你還需要alphabet soup，國際化，本地化，以及易於訪問．而這說到的最後一點，自AJAX它誕生以來，就一直是開發人員的痛．AJAX的反對者們大聲嚷嚷：“好啊，你別想向政府部門賣出任何AJax應用程序，因為有Section 508法案．”的確，有大量的實事擺在了面前，但不管怎麼樣，web應用程序必須是易於訪問的．即使當你在制作頁面的時候，你也需要考慮到對多語言的支持，以及基於CSS的樣式設計．同樣，它還需要保證，不管在單元測試還是系統測試級別上都要求是可測試的．最後一點就是用戶體驗了，所有這一切來來回回最終還是從開發人員到測試人員然後再到達最終用戶．
現在，各種不同整合JSF和AJAX的方法都是為了降低復雜度。我現在為這些解決方案亮起了紅燈。（這些解決方案都）有很多的贊成和反對的聲音，但亮起的紅燈表明反對占了上風。那麼我要說的第一個整合JSF的方式就是直接使用Naked AJAX（未經過任何封裝的AJAX），你打算一切靠自己，什麼都打算自己寫! Frank Zammetti寫了一本書，他發明了“Naked AJAX”這個術語，指的是你不使用任何AJAX框架，全部由自己親自來完成。如果你這麼做，你會深入的理解AJax底層的技術，因此很可能你在職業上炙手可熱並且這也一切也確實是你想要得到的話，那麼我不得不說你太有才了。
你必須親自處理所有的使用XMLHttpRequest的交互請求，這就要求你有扎實的JavaScript基本功，使用SetTimeout函數等以及一系列常人所不願意使用的技術。到時候，你還不得不去解決跨浏覽器之痛，而這種痛苦對於web開發人員來說已經持續多年，最後為了與它有一個了斷，你還是陷入了開發自己框架的沼澤之中。
第二個解決方案顯得更高級些，因為你使用了JavaScript框架。現在已經有大量可用的JS框架充斥在我們周圍，比如Dojo,DWR,Prototype等，這些框架也是今天要討論的內容。但使用這些JS框架的話，你仍然需要去為你的web應用程序編寫代碼，而且一旦在JSF中使用了某個JS框架（比如說Dojo）的話，你又要去編寫那些侵入性代碼了。
Struts組件編程必須限定在Action/ActionForm/JSP這三個框框中做文章，難度相對比較大，而Tapestry/JSF則沒有太多這些技術框框限制，兩者在組件編程方面更讓編程者自由一些，方便一些，這也是組件型框架的優勢吧。
Struts標簽庫
在Struts中，經常需要使用標簽庫來顯示組件ActionForm中內容，這就涉及到一個結合的問題，標簽庫是別人寫的，參考Struts的標簽庫用法，而組件是自己的，難度和麻煩就體現在這個結合點上。
JSF基本思路和Struts差不多，只不過換了不同標簽庫，也需要標簽庫+組件的結合思考，不過因為組件這裡是通用組件，沒有什麼限制，所以這樣比Struts要輕松一些。
Tapestry使用了組件庫概念替代了標簽庫，沒有標簽庫概念，這樣就沒有標簽庫和自己的組件需要結合的問題，都是組件的使用，組件中分Tapestry標准組件和自己定義的組件，這也是接觸了JSP體系的人學習Tapestry面臨的一個思路轉換。
具體以頁面跳轉為例子，頁面跳轉是靠鏈接 實現，鏈接是頁面經常使用的元素。
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聯盟的一貫策略。
當然，你也可以發表你在實踐中這三者任何一個的使用感受，以使得後來者有一個比較。
