Tapestry和Hivemind的出现

Howard Lewis Ship从13岁起就义无反顾的沉迷于编程。他从1997年起开始开发Java Web应用。在2000年他成立了Tapestry项目。他是Tapestry和HiveMind项目（都是Apache Jakarta的子项目）的开发负责人。他撰写了Tapestry的权威著作，Manning出版社出版的《Tapestry in Action》一书。他现在是一名独立的咨询师，专长是Tapestry的培训和指导。他和他的作家妻子Suzanne居住在美国麻省波士顿附近。

Hi Howard 自我介绍下吧。

好的，我是Howard Lewis Ship。我是Tapestry项目的创建者和开发负责人，Tapestry是一个创建Web应用的开源Java项目。最近，我又从Tapestry分离了一些技术并发起了另外一个叫HiveMind的项目，它是一个service的框架，用于更便利的方法创建应用。

那什么是Tapestry还有它的由来是什么？

Tapestry是在我经历的基础上创建，当时我在波士顿一家叫Primix的咨询公司上班。在那里我们有一个大小非常适合的团队，8到10个涵盖了各种经验层次的员工。有一些非常年轻、刚从大学出来的新手，通常分配给一些经验丰富的老员工来带。我们在做Java方面的工作，使用初期版本的J2EE。甚至有更早的时候，我们还在最原始的那种经常会出来一大堆问题的Servlet和JSP平台上开发过，通常并不能得到期望的结果，太郁闷了，每个项目看起来都陷入了痛苦的深渊。在加入Primix之前，我曾接触过WebObjects，它是Apple公司的一个基于控件的开发web 应用的 framework。经过初步的使用及自己写的一些小演示来初步体验，让我看到了使用控件方法开发web应用的无穷魅力。正好我在Pipeline那一段时间没有什么项目，大约有一到两个月左右时间比较闲，期间我写完了一些初步的代码，然后它逐渐就成为了Tapestry。我继续完善它，花了好几周完成了第一个原型。然后不断的不断的给它添砖加瓦，整个过程非常有趣。

请问Tapestry和Struts以及其它的一些web framework有什么区别？

如果你观察一下Struts，WebWork或是其它一些framework，它们都是以操作为核心，将URL映射到某个操作。这些操作可能被称作是Servlet或是Action。当你在创建这些Servlet或Action时候将会受到各种约束。因为在J2EE服务器里面，一切都是多线程的。因此你不能使用实例变量，你必须将你的业务逻辑放在Action里面某个地方，然后又将状态信息存放在request或是session等另外的地方。你的大量精力将会陷入在这些问题里面，要考虑怎么样命名参数，怎么样构建URL，怎么样将URL映射到Servlet，怎么样返回给客户端参数。熟练的开发者好象都已经习惯这些了，但很难期望所有的人，尤其是新手也要在这样的环境开发。我们背负这些沉重的负担，多线程基本上是一个基于事件的模型，而不是传统的桌面类型。

Tapestry是以控件为核心。就是说你的应用是页面组成的，页面是由控件组成，控件也可由控件组成。Tapestry有一个完整应用所需要的一系列蓝图，它可以为你做很多工作，通常这些都要你自己动手来做。比如自动帮你处理和调用URL。你仅需要创建控件然后告诉Tapestry当你点击链接或提交表单时调用这个控件即可。你会发现很多代码你都不用写了，因为它已经包含在framework中，它已经写好在那里并且经过了测试。你知道servlet是很难测试的。因此让framework多做些工作，为应用提供页面，控件等形式的蓝图。它会承担大部分枯燥无味的重复工作，承担大家都比较烦的那部分开发和测试工作，因为这些工作如果你自己来做，没做好以后就会带来麻烦。

这听起来有点象JSF。你对JSF标准是怎么看待的？Tapestry和它比较有何区别？

JSF它来了来了来了呵呵……。JSF它是那种boogie man类型，追赶着其它所有的web application framework。我想JSF和我们的范围和目的不同。它是JSF模型的一部分。

你刚提及到JSF，JSF它承诺有工具支持，不知道Tapestry有没有工具支持的计划？

我刚说过，在Tapestry里面，你最重要的工具是你的HTML可视化编辑器，如Dreamweaver什么的软件就能很好的工作。如果你使用Eclipse平台，加拿大Intelligent Works的Geoff Longman已经实现了一个非常优秀的Eclipse插件Spindle。Spindle在我的书中强调得不够。它确实是一个非常好的工具，因为在Tapestry里你需要创建HTML模板，Java代码还有XML的页面配置文件等。但是这些元素是分散在不同的文件里面，一些在模板里面，一些在Java代码里或其它不同的地方。Spindle将这些统一了起来，在你编辑HTML的时候它可以自动从你的配置文件中获取相应的信息而支持自动完成功能。你可以很方便管理这些关联的元素，很方便在它们之间跳转进行管理。更酷的是他本人也是一位Tapestry的使用者，他有他自己的Tapestry版本。当你进行修改保存时候它会自动在Tapestry里面运行以便检查错误，所以说它非常好。虽然Tapestry有非常非常好的runtime exception报告机制，我也确信他是目前最好的，但是你也不一定要用得上它。因为Spindle在你保存文件的时候它就会帮你指正错误。因此开发人员使用Spindle，美工使用标志的HTML编辑器，你需要的全部工具就都有了。

一些开发人员和设计师对URL方面有些抱怨，你是怎么看待这些意见的？（译者补充：Tapestry目前版本所有的URL都是框架生成的，用户无法干预。）

我一直对这个都比较慎重。我所做过的所有程序从URL方面来说它们都不是那么重要。我从来没做过一个应用使用J2EE的基于URL的安全机制。因此直到现在我认为这个问题不是很高优先级要做，Tapestry生成的长串的URL机制并不是什么大问题。不过当我们的用户基数增长时候，当更多人使用他的时候，项目的一些开发贡献者象Eric Hatcher确实说过我们应该更好的来处理URL的问题。它将会是Tapestry 3.1的关注焦点，我们现在也正在忙这个。

至于3.0版嘛，呵呵，你还得忍受这种难看的URL。

Tapestry 3.0 final 版本有什么新内容呢？

和上一个版本，就是还是在SourceForge的Tapestry 2.3相比较，有什么新内容呢？首先是License改变了，使用了Apache的License ASL 2.0。我们的项目转到了Jakarta，大量新的开发贡献者加入项目，令人振奋。从特性方面来说，大的来讲就是在2.3版中是比较结构化的设计，所有的配置都放在一个叫application specification的配置文件里面，然后在这个文件里面每个页面有它自己的一段。但是新版Tapestry每个页面都有一个自己的XML配置文件，我们称为page specification。在HTML模板里面，你只需要引用这些控件，然后在page specification里面配置好这个控件的类型，参数以及其它信息。所以新的开发者很快就可以用Tapestry上手，他只要添加一个HTML模板，一个page specification文件和一个Java文件就可以工作了，甚至你还可以用Spindle插件节省很多工作。另外一个Tapestry 3.0的重大改进是我所讲的隐含控件，这种控件你只需要写在HTML模板里面，有点象JSP，可以把类型，参数等设置信息都写在HTML模板里面，因此连page specification都不用写了，至少对于这个控件你不用写page specification。所以配置起来更简单，在模板里面就可以看到所有的东西。我在我的书中几乎都是用这种隐式的方法示例，因为看起来更直观。而且更酷的是你可以自行选择用哪种方法（显式或隐式），即使同一个页面中你可以混合使用两种方法。因此它是Tapestry 3.0的主要特性。另外新版当然增加了很多有用的控件。如我最爱用的是那个日期选择的控件，它是一个漂亮的基于Java Script的下拉日期选择控件。至于那些极大提高效率的功能，除了隐式控件，RAD样式之外，那就是我强调的exception报告机制。它的由来说来话长，我曾在邮件列表上收到个一个埋怨，大致就是说“当Tapestry报错的时候可以看到一大堆垃圾信息，能不能直接告诉我是配置文件哪一行引起出错的呢”，我当时回信说这个要求太离谱了，因为没办法可以做到这样。但是两周过后我又看了一遍这个邮件觉得这个提议还是可行。因为每一步操作，如读取配置和模板，它创建对象，它可以一直跟踪回去，然后确定究竟是哪一行配置创建了一个对象。所以在运行期间，它确实可以将这些信息提供出来。如它可以告诉你Home.HTML 13行或者其他什么地方有错误。当我在写书调试我的示例程序时候也得益这个功能，当出错时候我不用一行行去查错，弄清楚究竟是哪里出错了。我再想想3.0版有哪些新东西……对了，我们有大量改进的文档。我们编写了很多文档，增加了很多特性以及控件参考手册，我们还将会提供更多的文档。

你在这个精确错误报告的功能上花了多少时间？有多大的工作量？

我们来聊聊Tiles吧，Tapestry有没有一个类似Tiles功能的地方？它是不是需要一个这样的东西？

Tapestry没有类似Tiles的东西，因为它不需要。Tapestry是基于控件的。页面本身也是控件，可以由控件来创建，和JSP不同，Tapestry控件可以有它自己的HTML模板。而且它们是智能的。

对于一个Struts开发者开始用Tapestry最大的观念转变是什么？

有很多使用Tapestry的用户都是由Struts过来的，甚至有WebWork的经历。他们会在Tapestry里面寻找他们熟悉的那些东西，可能会问“如何将URL映射到Action里面”？当然你并不需要做这个，Tapestry已经帮你搞定了。你需要建立的意识是，你有了页面，有了控件，有了后台的操作，剩下你要做的仅是完成Java代码里面一个供框架调用的方法。许多人经常问如何才能访问Servlet API，虽然这也是可以访问的，但你完全没必要这样做。如果你想在在服务器端保存数据，你可以存在页面的属性里面，然后让属性保存即可。Tapestry自己会管理如何在HTTP session中保存和传递这些数据。因此在这个方面，如果你寻找你期望那些东西他们完全是不同的东西。我仍然不能理解为什么大家还要在Tapestry里面要这个，当你学会了那些烦琐的东西之后你需要做的是忘记掉那些在Servlet，Struts中折磨你的东西，不要在Tapestry里面继续了。

Tapestry即将添加的功能有哪些？

如上所讲，管理URL将越来越重要。现在你要是观察一个有数百个页面的真正的Tapestry的大型应用

为了发挥HiveMind的优势，Tapestry实际上已经进行了重构。HiveMind是我另外开发的一个微内核的service框架。

还有很多其他大家感兴趣的特性。在WIKI上有一个长久的讨论。如3.1版应该怎么搞啊，3.1版是不是又要象3.0版一样搞个一年半，还是说6个月就搞完，要添加哪些，干掉哪些。很多人都有很多好主意。这些都在Jakarta的WIKI上，大家对发展有兴趣可以去看看。

如何让Tapestry 和Spring，Hibernate以及其它一些持久容器一起工作？

大家确实喜欢Tapestry和Hibernate结合工作，在过去的一年到一年半的时间做了大量工作。我意思是说有人做了几个不同版本使用Tapestry + Hibernate的PetStore。我自己也在学习Hibernate。我想很多人都只用到了J2EE的小部分功能，因此他们希望有轻量级的方案。他们可能有一个Tomcat或Jetty再加上Tapestry和Hibernate，它们之间可能用到Spring或HiveMind。Spring有很好的Hibernate支持，当然从Tapestry的页面也很容易访问，因为Tapestry的页面是真正的Java对象不是脚本。当然整个来说Tapestry是表现层，因此你可以自由选择持久层的方案，用Hibernate或是什么，应用服务器也可以自由选择Jboss，BEA WebLogic等。然后将它们放在一起。人们高兴的是可以自由选择喜欢的东西然后把它们组合起来工作。

能不能给我们介绍一下HiveMind以及它的由来？

HiveMind主要从三个地方成长起来的。当我在WebCT工作的时候，它有一个叫Vista的大项目，Vista是一个企业级的教育培训软件，因此非常非常大，有上千个Java页面和JSP页面。我很少碰到过象这样的大项目，因此当然对在这里的所有项目很感兴趣。项目要求紧迫的进度，开发团队也分布在印度、麻省、温哥华、英属哥伦比亚几个不同的地方。因此项目包含很多东西，没有哪一个人真正了解Vista项目的全部进行状态。但我有幸见识了项目不少的方面。项目中需要在某些方面做一些重构的工作，并且初期就在如何合理化启动和停止方面预留了接口，因为它在BEA WebLogic上面运行，有很多工具在一起工作，每个工具都需要在启动的时候做一些特殊的工作，打开数据库表缓存一些数据、或者是建立一个JMS连接等类似的事情。我曾经致力提出应当建立一个微内核来做这些事情，而不是每个地方都来写一段Java代码。他们在碰到确实需要一个类似HiveMind这样的工具来处理启动和停止功能时候也给了我一点动力。因此我就为这个目的开发了HiveMind，而且HiveMind的想法是成为Eclipse plug-in API一部分，你有一个微内核，它知道如何来从plug-in中合并各个元素。现在Eclispe的tools里面，他们的plug-in API是

你能使用HiveMind进行配置工作吗？

当然，这就是它的主要功能。HiveMind的主要目的是配置你的应用

讲得好。当前Java中哪方面的技术令你比较兴奋？

Java方面很多都在进行。我想我最期望的是Java的注释（annotation）功能，它将会给类似Tapestry和HiveMind这样的Framework带来某些改变。所以你看到现在有很多有趣的工具在做这样的事。但我认为我喜欢Java的一点是它象其他一些语言如PL1和Object C，已经工作得够好了。我想有一种理论是今天我们碰到的所有问题，都可以用一种新的语言来弥补它没有的一两种特性。我们以前见过，或许过去的更现实一些。相对Java来说，你不能具有garbage collection功能，如C语言一样。这些将限制你构建的应用的复杂程度。我依旧认为Java在服务器端已经做得够好了，虽然我也对其他一些语言感兴趣，如Groovy。我喜欢脚本语言的理念如Groovy和Python。我不想为了一两个新的特性放弃掉现有的东西，那意味又要重新完成这些烦躁的工作，又要去考虑初始化，配置以及连接等等。因此我认为Java就是一个用来构建强大方案的肥沃土壤，完全没有必要去追求另外一种神奇的语言，然后推倒所有的现有资源重来。另外我想谈的是，我认为Groovy确实非常迷人，或许当它稳定以后可以考虑在Tapestry里面一些合适的地方使用它。

你希望看到JCP改进吗？

当然。在我眼里JCP是有点问题。如果你仔细观察JSF一下如我参与的一个JSR－JSF，漫长的前期时间，结果所期望无条件相信，JSF是否能工作，是否具有扩充性，能否处理一些现实中存在的真实的复杂应用。我想我们真的需要一行一行去读RI(参考实现)才能知道.