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