canonical

   JSF(Java Server Faces)技術(shù)從發(fā)布時間上看已經(jīng)是一種比較古舊的技術(shù)了，但是目前仍未能成為主流的開發(fā)實踐。從我知道這種技術(shù)開始, 我對它的判斷就與我最早對于EJB的判斷一樣, 它們都在某種程度上捕獲了真正的需求,但是因為它們自身詭異的技術(shù)路線.我很懷疑是否這些標(biāo)準(zhǔn)制定者故布疑陣, 便如Microsoft的OLE技術(shù)一樣, 故意拋出一個錯誤的方向, 將大批組件開發(fā)商帶入死局.
   JSF技術(shù)是一種雙重的存在：它首先是一種標(biāo)準(zhǔn)，然后也提供了一種缺省的實現(xiàn)。但是從這兩方面，我都無法看到JSF的未來。
   從設(shè)計上說，強(qiáng)類型的視圖模型對象層與Witrix的架構(gòu)設(shè)計原則嚴(yán)重沖突。Witrix的基本架構(gòu)是瀏覽器和后臺服務(wù)器通過具有顯明語義的url實現(xiàn)兩分，這也是所謂REST風(fēng)格的一種內(nèi)在要求。隱蔽了鏈接的技術(shù)破壞了基本的web超鏈模型. 為了獲得那么一點(diǎn)點(diǎn)結(jié)構(gòu)控制能力, 做出這樣的抽象是不合適的.JSF的配置模型繼承了structs的傳統(tǒng)，仍然是那樣的冗長繁雜。我們是否真的需要這些配置文件，還是希望像ROR那樣在代碼中直接完成一切？
   不能在標(biāo)準(zhǔn)的瀏覽器中預(yù)覽. 可以說創(chuàng)造了一個JSF IDE的市場, 但是這無疑是一個無聊的市場. 現(xiàn)在有一些備選的方案, 如Facelets, 使得jsf可以采用屬性語法, 但是只要想想僅僅為了這么一點(diǎn)小小的修正所需要付出的開發(fā)量就足以讓人崩潰。
   JSF提供了組件級別的事件響應(yīng)機(jī)制，因此似乎是AJAX應(yīng)用的理想場所．但從Witrix平臺的開發(fā)實踐來看，JSF對于AJAX的使用是受限制的，有著很大局限性的．組件事件響應(yīng)并不一定要采取JSF那種體系結(jié)構(gòu)．
   從實現(xiàn)角度上說，基于jsp tag可以說是JSF的致命弱點(diǎn)之一. jsp tag從設(shè)計之始就一直是未經(jīng)過實踐考量，其設(shè)計無法支撐復(fù)雜的控件架構(gòu). 特別是早期JSF與標(biāo)準(zhǔn)的JSP tag不能互通實際上是明顯的設(shè)計缺陷, 而且性能問題是內(nèi)置在該設(shè)計中的. 現(xiàn)在雖經(jīng)多個版本的不斷補(bǔ)救, 但是為了兼容性, JSP Tag負(fù)擔(dān)過重, 它始終是基于文本處理模型，實際上不可能有什么本質(zhì)性的進(jìn)步.　JSP tag模型過分孱弱必然造成JSF設(shè)計中大量處理過程堆疊到界面對象層，更加劇了JSF的模型復(fù)雜度和性能瓶頸。 實際上根據(jù)Witrix平臺中tpl模板技術(shù)的設(shè)計經(jīng)驗，大量界面構(gòu)建過程是可以在模板層以直觀的方式完成的，而不需要借助視圖模型對象。
   所有問題的一個集中體現(xiàn)就是增加一個新的JSF組件絕對不是一件平凡的事情．如果有一天這個問題可以得到解決，那時的JSF從思想和實現(xiàn)上都必然和現(xiàn)在的JSF有著本質(zhì)性的區(qū)別．