選擇JSF的理由：從UI組件開始
記得華為總裁任正非說過，華為是因為無知才走上通信產業之路的。我在2004年年中開始接觸JSF時，也是因為無知。幾乎沒有Java經驗，Web更是一片空白，寫了一個半吊子的JSP程序后，我居然判了JSP的死刑，鐵下心來鉆研我的JSF去了。無知者無畏，說得一點也不錯。
從JSP起步，第二級臺階，也許Struts是最合適的。沒有復雜的概念，沒有深奧的理論，容易理解，上手快，從JSP向Struts的過渡顯得特別自然。這是Struts流行的原因之一。如果當時請教過任何一個Java高手，我十有八九會以Struts作為我的JSP替代技術，并且很有可能成為Struts的發燒友?？墒?，機緣巧合，我選擇了JSF。
正應了那句俗語：“傻人有傻福?！辈捎肑SF技術后，Web編程如有神助，一個月時間，我和一個剛畢業的程序員寫出了一個規模不小的Web程序：126張數據庫表，346個JSP頁面，458K Java源程序，還包括84頁的《需求規格說明書》和189頁的《數據庫設計說明書》。即便是桌面應用，這樣規模的程序在一個月內完成，老板也該偷著笑了。其實，效率的提高，完全是JSF的功勞。正如Sun在JSF的規范中所宣稱的那樣，JSF極大地簡化了Java的 Web編程。
首先，在JSF中，頁面干凈了許多。無需聲明Javabean，也不用嵌入Scriptlet，沒有多余的符號，只是一些擴展標簽而已，看上去規范而不失優雅，讓人賞心悅目。程序員多半是完美主義者，眼睛里容不得丑陋的代碼，我認識的一些程序員，平時不修邊幅，可以整個冬天都穿同一件夾克，袖口磨得油光發亮，但他們的程序卻整潔得讓人嫉妒。
其次，JSP中趾高氣揚的Request和Response對象淡出了JSF。在典型的JSF應用中，程序員基本上沒有直接操作Request和Response對象的必要，因為框架隱藏了對這兩個對象的處理細節。不論是從Request中解碼參數，還是將數據編碼到Reponse中，都不需要程序員寫任何代碼，JSF知道該怎么做。當然，如果非要訪問Request，JSF的隱含對象為程序員提供了可能。
JSF的UI組件
UI組件是JSF最具特色的組成部分。與桌面程序的UI組件不同的是，JSF的UI組件是服務器端的，但是，在JSF框架的支撐下，這些服務器端的UI組件，在程序員看來和桌面程序的UI組件沒什么不同。我用的Jbuilder版本不支持JSF頁面設計的所見即所得，當我拖動一個UI組件到頁面上時，Jbuilder為我生成的，是一段標簽文本，跟隨著我的鼠標，放在指定的位置。一個服務端UI組件就是這樣誕生的，其在頁面上的表現形式也隨之確定。
沒有所見即所得當然有點遺憾，但對我來說，這已經足夠了，因為把組件的Value和后臺Javabean的屬性進行簡單的綁定，我就得到了所有需要的程序行為。頁面顯示和后臺數據的同步、用戶輸入的轉換、數據的有效性驗證、錯誤信息的提示以及UI組件狀態的保存和恢復，所有這一切不需要我寫任何代碼，JSF已經代勞了。
JSF的另一個特色是它的數據組件。我曾經很長時間使用PowerBuilder開發程序，熟悉PowerBuilder的程序員都知道，PowerBuilder最引人注目的是它的所謂數據窗口。并不好看的界面，笨拙的IDE，PowerBuilder單單憑借一個數據窗口，就吸引了大批程序員。PowerBuilder與數據庫是天生的一對，長期使用PowerBuilder的結果，我養成了以數據庫為中心的設計習慣。
這個習慣一直保持到今天，幾乎成了我的嗜好，前面提到的126張表，就是最好的例子，換成別的程序員，也許30張表就夠了。
所以，JSF的數據組件讓我一見鐘情。數據組件實際上包括兩個組件，一個是UIData，一個是UIColumn。JSF將數據表看成是由若干個列組成的一個表格，而行的數目取決于數據源中數據的條數。這與PowerBuilder的數據窗口殊途同歸。當然，數據組件不是直接從數據庫中取得數據（實際上，設計模式也不允許程序員這樣做），而是通過一個Javabean以resultSet的形式傳遞給數據組件。在JSP中，這樣的程序邏輯夠我折騰一陣的了，而在JSF中，這和生成一個文本輸入框一樣容易。
JSF數據組件的用途并不限于顯示數據庫表的內容，實際上，所有實現了List接口的對象都可以成為數據組件的數據源，這給Java的Web編程帶來了極大的便利。而且，如果你想直接編輯數據表中的數據，JSF也可以做到，只需以可讀可寫的方式，將UIColumn的value屬性和數據源中你想修改的屬性綁定在一起，用戶在網頁上所做的修改，就會自動保存到數據源中。這樣的功能，在JSP中，程序員都要深吸一口氣才敢動手的。我的第一個JSF程序，之所以能在一個月的時間內完成346個頁面，數據組件功不可沒。
【編輯推薦】
