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