为Tapestry做了个额外的功能：Tapestry webflow

昨天，花了一天的时间终于写了个文档出来。我讨厌写文档，尤其讨厌花类图。。。。。唉，语文学得不好，就是这么没自信。

TWF，基本上整体的运作模式，已经确定下来，并且做了一个购物车示例。可能从来没有以系统分析师的角度来考虑整体表现层与业务逻辑层的关系，所以这个购物车示例花了我不少时间。我不得不承认，对于系统分析师的思维方式，我很不适应。不过，当我做完购物车示例，再写文档来讲解TWF的运作过程之后，我发觉，其实系统分析师这个角色，对于一个项目的整体设计来说，有其存在的价值。

前两天，飞哥发了一份办公室主任去参加什么四川省软件大会之后的报告给我。四川省，70％以上的软件公司是不超过50人的小公司。实际上，记得《程序员》杂志对2004年的统计，全国接近60％的软件公司是不超过40人的小公司，我们公司也是其中之一。在这种作坊式小公司，一个人可能必须得担当多个角色的工作。因此绝大多数情况下，项目经理也只能把有限的精力投入到项目的灵魂中去：业务逻辑层的设计。只要业务逻辑层设计合理，那么业务逻辑层的开发相当迅速，而且直接影响项目运行效率的绝大多数不合理，也都是出在业务逻辑层。而表现层，实际上是处于一种无关紧要却又非常影响项目进度的尴尬地位。很多时候，项目经理将目光投向表现层，并不是因为关注表现层，而是表现层的开发效率实在太慢，到了难以忍受的地步。而且，表现层这破玩意看似简单，实际上其深奥复杂及其重要性并不亚于业务逻辑层。

在javaeye上，已经有人在大声疾呼“Spring MVC的灵魂是Spring webflow”。可能每一个接触过表现层的程序员都知道MVC：Model-View-Control。MVC几乎是表现层的灵魂定律。可是又有几个人能够说得清楚，Model-View-Control的明显界限是什么？并且能够在程序中实实在在，界限分明地体现出来？

到目前为止，我见过MVC最界限分明的框架，是Spring webflow。首先，Spring webflow是建立在Spring MVC之上的，Spring MVC能够将view与Java逻辑分离出来。其次，Spring webflow通过对XML的定义，能够将Model从Java逻辑中脱离出来，这样Java逻辑就变得非常单纯，仅仅是Control。当做到MVC界限分明之后，一切就变得很有趣。。。这种有趣性可以在大公司，特别是外企体现出来。在外企，核心代码都是老外写的，普通程序员只需要调用接口就可以了。同样在表现层，只需要完成View即可，至于页面要怎么跳转，跳转到哪里去，怎么与业务逻辑层打交道。这些核心东西，当然不应该是一个普通程序员所需要关心的。

上次和冰箱去参加IBM的Webspere培训，课间闲暇，我们就和那个培训讲师闲聊，我们说：“HO~，你们这个Webspere上的页面做得好冈，里面有很多JS，开发花了不少时间吧？”那个讲师答曰：“无所谓呀，反正我们有的是人，webspere我们投资了10亿，有几千个程序员在开发。一个人一个月就只做一个页面嘛，也够了。”。。。。就算一个人一个月做一个页面，有100个人在做页面。如何协调这100个人的工作成果？。。。靠的就是统一的项目管理，靠的就是MVC界限分明。只要有个高级程序员开发小组来开发核心Control层，那么有多少个人做View层又有什么关系呢？。。。我打赌，在IBM做View层的程序员可能压根就不知道下一个跳转页面在哪里。

如果说，TWF承担了Spring webflow的工作，那么Tapestry就如同Spring MVC。这就是TWF存在的价值。

不明白你们公司为什么要整合框架
旧的框架开发效率低，应该可以淘汰了

而且整合框架肯定免不了降低两套框架的灵活性

语文学的不好，并不能作为讨厌写文档的理由。

写文档需要很好的语文基础吗？不需要吧，只要你是中国人，会说中国话。