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