canonical

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