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