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開始。