09年4月我從A公司離職，被同事拉到一個創(chuàng)業(yè)團(tuán)隊做網(wǎng)頁游戲，他們當(dāng)時使用的技術(shù)體系是基于Seam的。而我則是SSH的忠實用戶，此前一直跟隨江南白衣、appfuse的路線，大大小小也做了一些項目，也自己攢了一堆輪子。花了1年多的時間在一個基于元數(shù)據(jù)的基礎(chǔ)框架上面，那時候我基本上掌握了maven的簡單使用，于是自己做的一些基礎(chǔ)性的東西也都是使用maven來做依賴管理、版本發(fā)布。
此前我曾經(jīng)了解過一點JSF的內(nèi)容，結(jié)果是不喜歡JSF這個框架。理由有兩點：
一是控制不了一些想控制的細(xì)節(jié)。例如表單項的id,name都被JSF接管，而JSF生成的形如formId:inputId的id/name也讓我看著眼暈。頁面加載后，在瀏覽器上點擊右鍵查看源代碼，如果你曾經(jīng)做過，那么一定深有體會——慘不忍睹。JSF生成的客戶端代碼是相當(dāng)難看的。這一點讓我很不爽。
二是作為一個基于事件模型的框架，和傳統(tǒng)的mvc框架有很大程度上的差異，沒有swing/vb經(jīng)驗的我對于事件/組件模型還是比較陌生的，于是有很多事情搞不明白。JSF使用commandButton/commandLink來提交表單，作為開發(fā)人員無法控制每一次請求的參數(shù)組織過程也讓我覺得不爽——某個按鈕一點擊，總是把當(dāng)前form里面的全部內(nèi)容提交到服務(wù)器，別無選擇。也許你想向服務(wù)器發(fā)送一個簡單的請求，自己拼幾個參數(shù)，最后調(diào)用到服務(wù)器端的某個Action的某個方法，而這個在Struts1/2里面被簡化到了極致的過程，在JSF中實現(xiàn)的話，相當(dāng)困難。
我沒有看過seam，也不甚了解。但是基于以上的針對JSF的映像，不太看好這個深度依賴JSF的框架。
在后來的1年多的時間里面，我逐步學(xué)習(xí)、了解。我越來越了解我真正需要的是什么樣的東西，我被JSF吸引了，我體會到了基于jsf/seam的快速開發(fā)相對于spring和struts的巨大優(yōu)勢。我終于了解到，自己以前遇到的那些難題，在JSF、Seam體系中是如何輕易的被化解。沖動的我以非常堅定的態(tài)度確信：從struts代表的傳統(tǒng)mvc，到JSF代表的組件、事件框架，這是一種進(jìn)步。那時，我還沒有足夠的視野去評判他的適用范圍。
10年4月我從該公司離職，到了另外一家電信行業(yè)軟件公司。當(dāng)時部門正處于項目間歇期，人們相對比較閑，主要工作是整理、積累、沉淀。在后來的幾個月中，我主導(dǎo)設(shè)計、開發(fā)了基于Spring+Hibernate+Ibatis+JSF的組件集，我們使用maven管理發(fā)布和依賴，引入敏捷的理念，基于行業(yè)軟件的開發(fā)經(jīng)驗自定義需求，最終形成了基礎(chǔ)組件管理、JSF集成和擴(kuò)展、基于spring security的權(quán)限、基于osworkflow的工作流等一系列組件。后來的商業(yè)項目開發(fā)中，事實證明這些組件、開發(fā)和管理方法，極大的提高了開發(fā)效率。
又一年過去了，該項目已經(jīng)進(jìn)入尾聲，基于這一套組件的其他項目也即將上馬。我想，現(xiàn)在是個比較恰當(dāng)?shù)臅r間，回過頭來，回顧，總結(jié)一下，發(fā)幾篇blog。那么，從JSF開始。