Tapestry应该会成为web表示层的主流框架

每个框架都有它的适应性，我之所以对Tapestry的感兴趣也是出于当时所负责的项目。

02年下半年我负责公司的一个产品的研发工作，主要目的是提供一套企业应用的开发框架，类似于Portal/EIP，实际上我们的架构在业务的体现 上是以OA形式出现的，对于一个OA产品，关键是要提供一套相对完善的机制来简化实施任务，尽量将客户的个性化要求通过配置工作来实现，而不是进行开发。

在企业的应用中很多应用是基于文档和流程的，比如公司新闻、公司公告、企业知识库、档案管理、项目管理等，主要是信息发布和公文流转应用，我们希望 能把一些通用的业务产品化，然后在实施的时候可以让实施人员灵活配置，包括对业务过程、文档内容中的字段属性、校验规则、业务流转规则、业务规则、组件表 现、页面布局和样式等进行配置，同时可以嵌入脚本来适应用户的定制需求。

文档型应用很多是基于工作流引擎和文档引擎的，支持规则的配置和外挂脚本的嵌入，规则的配置和脚本都写在配置文件里的，业务规则中需要对业务组件的 属性和方法进行操作，外挂脚本也是，这就要求Web的应用开发必须是组件式开发，业务组件的属性和方法是可以写在流程的流转规则和控制规则里，并且可以被 外挂脚本调用，应用程序中各个单元是组件方式。

同时，既然是产品，在表现上必须考虑用户的个性化要求，从组件表现到整体页面都应该允许支持独立的客户模板，要求业务和表现完全分开，并且要支持事件编程。这时传统的Web应用开发方式已经不能满足要求。

在完成工作流引擎的初始版本后，我们开始研究流行的框架，包括Struts、Turbine还有Echo、JSF等，Struts首先被放弃，因为 它的导航机制和我们的引擎冲突，并且用的是Taglib，和我们所要求的“干净”模板需求冲突。Turbine的问题是它的模板定义vm文件采用了它自己 定义的$形式的语法标签（是个完全独立的模板语言，看来设计者以前是个Perl程序员，：），后来我们在用Jetspeed做门户应用的时候，发现它的应 用框架用的是Turbine，当时头就大了，呵呵），这就更与我们的要求背离，Turbine真正好的地方是它的O/R Mapping等服务工具部分。Echo的设计是组件思想，但表现竟然采用类似Swing的编程方式，太疯狂了。JSF倒是提供标准的事件处理机制，但很 难接收它的组件标签方式，实际上还是变相的Taglib，没有什么本质的改进，还是不适合。

后来我们发现了Tapetry，当时的感觉就是这就是我们要的东西，确实它的架构非常切合我们的需求。

每个Tapestry application，我们理解为一个完整的应用模块，由一个.application配置文件进行定义描述，里面定义了这个application所 包含的page和component。每个page也由一个.page配置文件进行定义描述，在Tapestry中，每个page包括一个.page文 件、一个HTML模板（标准的HTML文件）和一个Java类，Java类是可选的。.page配置文件中，可指定与这个page对应的Java类、所引 用的Bean和html中用到的component。

另外在工作流引擎中，Activity活动之间数据的传递机制也在Tapestry中得到完美解决，不再采用request、response和 session方式，page之间传递的是visit对象，visit对象用于在page之间传递application内部专用数据，这和工作流定义的 应用相关数据处理方式非常吻合。

至于页面表现，在页面html文件里，只要在需要插入组件的地方写上“jwcid”之类的属性后进行编码，不会对模板页面的设计造成影响，可以正常显示页面制作人员的工作成果，这样页面和程序可以完全分离。

当看完它的文档后，我们做了一个很简单的例子，效果很好，也非常容易理解，如果不是后来的一些事情公司搁置了这套引擎的开发，也许现在我们已经完成了这个框架，也可以详细的叙述Tapestry的优缺点了。

通过对Tapestry的初步分析，个人觉得Tapestry的思想比较符合我们目前的应用设计和开发思想，由于它封装了Servlet，完全以组 件驱动方式来处理请求、生成页面，并实现了页面和程序的分离，从这些方面看，比Struts、Turbine这些框架要先进得多。

不过毕竟没有非常深入的研究Tapestry，需要通过实际的开发来掌握它，希望能看到更为深入的剖析文章。说句心里话，Tapestry的技术很 好，就是对于Apache，现在都有点不放心了，每个框架都来自己的一套，由于无法集中力量，项目越来越平庸，很多不如专业做某一块技术点的开发项目做的 好。O/R Mapping做的比较早，但已经落后于Hibernate了。

另外采用Tapestry，也要考虑到它的适应场合，如果采用的是胖客户端机制，如我们原来的web应用框架或者dlee他们的应用框架的话，Tapestry框架就可能不是很合适，毕竟它还是基于Thin客户端机制来设计的。

采用哪个框架，实际上取决于项目的特点、公司技术力量、历史经验成果，架构设计人员的目标和喜好，同时要项目组的伙伴容易理解和很快上手，在开发过程中，能有效的适应专业化分工要求、容易测试，这些综合性的因素决定了最终所用的框架结构。