Seam與JSF的加減法
JSF的加減法
JSF 本身是很多問題的。當然，JSF不是一項技術(shù)，而是標準?？纯?javax.faces.* 包里的內(nèi)容，不是抽象類就是接口，是沒有實現(xiàn)的。 JSF 出來的時候目的也不是面向應(yīng)用開發(fā)者的，而是面向組件供應(yīng)商的，從這點意義上來說，JSF是成功的。Sun提供了一個reference implementation, 但是那更像是教組件供應(yīng)商如何做組件的一個demo，而非真正意義上的給應(yīng)用開發(fā)人員用的成型的組件。
標準因為要融合各方需求，所以內(nèi)容只能是各方能力的交集。至于標準之外的東西，則需要各方去發(fā)揮。
JSF標準因為是先于成型的應(yīng)用出來的（不同于EJB3的借鑒hibernate和spring，JSF299的借鑒seam），難免會有預(yù)見不足的地方。在某些地方可能作了過分的限制，而另外某些地方則完全沒有規(guī)定放得太開導(dǎo)致標準實現(xiàn)商完全忽略了它們。
但是 JSF 的初衷是不錯的，而且標準本身也足夠的可擴展。 所以現(xiàn)在才會誕生如此多的基于 JSF 的框架。 這些框架在不同程度上修復(fù)了 JSF 初始制定時的不足。
Ajax4JSF, Facelets, Seam 是這其中三個獨立的方向。
1. A4J: 用網(wǎng)絡(luò)檢測工具可以清晰地看到，每次在JSF postback 的時候，雖然可能只有部分頁面需要刷新，但整個頁面都會被從服務(wù)器送往瀏覽器。這是非常浪費的。 JSF的event-driven模型實際上非常適合部分頁面刷新（試想如果沒有事件模型，每晃一下鼠標顯示器就把整屏幕重畫，現(xiàn)在也就沒有 windows了），但是因為ajax出來的時候JSF標準已經(jīng)final了，就沒有把Ajax考慮進去。對于事件模型來說，把整屏幕重畫改為部分組件重畫是件相對容易的事情，這也就是 Ajax4JSF 這個項目的目的。是否開啟AJAX，可以不需要javascript，只是更改頁面中的某個開關(guān)（tag）就行了。
2. Facelets: JSF是建立在JSP上的，但這是完全沒有必要的。JSP不是模板語言，它只是簡單得把嵌入在html里的java語言原樣放入Java的源文件里，實際上是混合的html和java。這種模型和JSF的事件模型沒有任何互補的關(guān)系。相反，它給JSF加入了不必要的限制。Facelets的目的在于取代 jsp在JSF里的地位。它是真正的模板語言，el表達式可以嵌入在頁面的任何位置，比如寫成：
<h2>Hi,I'm Jordan, I think the winner of this cup is #{winner.name}, is that right?</h2>
Facelets不需要編譯，頁面是hot-deploy的，性能比jsp快。另外，facelets本身提供了加參模板的功能，定制新的組件可以完全不寫java，只把頁面里的需要提成組件的內(nèi)容扔進分離的頁面，并且在taglib.xml里面加入tag指向分離的頁面，并指定參數(shù)名字就可以了。 JSF最為人詬病的組件缺乏的問題，在facelets這里得到了緩解，實際上是不怎么需要第三方組件就可以快速寫出舒服的代碼來。Facelets還有其它的功能，比如debug頁面顯示facelets頁面出錯的行號，比如無限嵌套的模板，等等。
3. Seam: Seam 其實本身是無關(guān)JSF的，但是因為它從一開始就建在JSF上面，所以也不得不對JSF的一些問題進行修復(fù)。
Seam的工作需要分開來細說：
◆page行為
◆Context-filter
◆RESTful（重建頁面參數(shù)）
◆異常處理
◆跨越重定向的狀態(tài)
現(xiàn)在我們有了JSF的加減法：
JSF - (全頁面刷新) + Ajax4JSF - Jsp + Facelets + 全局Page行為 + Context-filter + Restful參數(shù)綁定 + 可定制異常 + 跨越重定向的狀態(tài) = “ -_- ！一大碗炸醬面”
就好像一件黃金圣衣，經(jīng)過無數(shù)次修補，雖然還能再用，但是實在不如重鑄了。
JSF 需要一套整合的模型，使這些各個分散的部分重新以一種整體的局面展現(xiàn)出來。它需要把多余的東西拋棄掉，把新的內(nèi)容以更集成的方式融在一起，因為光是熟悉這些不同分散的部分，理解它們之間的關(guān)系，知道哪里會有BUG，哪里則可以避免這些BUG，并且在運用的時候總是用對該用的東西，這已經(jīng)使人非常頭大了。 JSF作為標準來說是成功的，在這一標準下有了如此多的可以插拔的第三方軟件。但是該是時候?qū)@些零散的東西統(tǒng)一了。就好像ubuntu在統(tǒng)一的指導(dǎo)思想下集合了盡可能多的零散的開源軟件，使它們可以被一種簡單并且相似的方式獲取，使我不需要像在Gentoo里安裝任何一個東西都要搜索搜索再搜索，了解它的來源，了解它的BUG，了解我的硬件是否支持。作為用戶，我不想學習，我想有明白的人替我作決定，那是***的，特別是當這些決定make sense的時候。
現(xiàn)在的Seam正是朝這個方向走的。能走這樣的路，得有兩個條件，一是有眾多零散的可用的東西，但是它們?nèi)狈y(tǒng)一的形式（但它們得有能夠統(tǒng)一的背景，比如 ubuntu下是posix標準，Seam下是JSF標準）；二是有對該領(lǐng)域非常熟悉的人來做這樣的事情。上面提到的Seam對JSF的改進其實只是 Seam框架下非常小的一部分，是Seam在向這個目標前進的必須的一個步驟，是在Seam內(nèi)核基礎(chǔ)上水到渠成的東西，而遠非Seam的全部。正如 Seam的名字所示：縫合；正如ubuntu的名字所示：分享與同在。它們的制定者在決定之初即是向著這一目標前進的。
已經(jīng)early draft review的JSR 299， 即是借鑒了Seam（以及其它比如Guice）的一個標準，試圖把這一方向推得更遠。
至于對于縫合所需要的本事，Seam的conversation模型，CoC理念，元注解配置+xml補充方式，動態(tài)雙向注入模型（不同于spring的靜態(tài)單向注入），擴展了的EL等，是其基礎(chǔ)。內(nèi)部事件和監(jiān)聽模型，和drools的安全集成模型，和hibernate-seach, hibernate-validation, seam-remoting, jbpm,groovy,itext的集成，是其在基礎(chǔ)之上的應(yīng)用。這些則需要另外的文章來寫了。
不說Seam誕生的大環(huán)境和Seam產(chǎn)生的語言基礎(chǔ)，只是說Seam本身的功能，大概也可以，不過我認為非常多的外在功能都只是某些環(huán)境外在因素和基本內(nèi)在因素所決定了的。大環(huán)境和內(nèi)在可能定了之后，細節(jié)的東西只是做就可以了。所以沒有辦法，還是得繞開Seam本身說些題外話。
JSF的加減法說了一下 Seam誕生的環(huán)境，這是外在機會，是融合各種技術(shù)的可能性，是廣的緯度。 這篇文章說說java上的可能性，是何讓Seam具有了融合的本事，是內(nèi)在能力，從深的緯度上說吧。
【編輯推薦】
