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