采访与书摘《Pro Web 2.0 Application Development with GWT》

InfoQ 非常荣幸地向大家推出《Pro Web 2.0 Application Development with GWT》一书的摘选，并因此有幸采访了本书作者——Jeff Dwyer。

1.GWT 在 Java 社区的地位越来越重要，市面上已经出版了很多关于 GWT 的书。相对于其它书来说，您的书的特点是什么？您觉得这本书最出色的部分是什么？

我觉得大部分编程类书籍的前半部分都在讲一些非常基本的东西，只要简单的了解一下 API 或者文档就能知道的东西，然后在书的后半部分列举几个例子展示一下如何实现某个特定的高级功能。这些书读起来很容易，但是真要坐下来开始开发程序的时候，你才会发现自己甚至还不知道该如何解决最基础的一些技术集成问题。我倾向于通过例子来学习，因而总是希望能够得到一些站点的源代码。学习 GWT 的过程中，如果把认识 GWT 所需的时间设为 X，那么将它与 Maven、 Spring Security & MVC、Hibernate & SiteMesh 集成需要的时间为 3X，而找到正确的构架模式则需要花上 5X 的时间。纯粹的 GWT 很容易，但集成却非常复杂。这就是本书着重覆盖的内容。本书解析了 1 万 5 千行代码的 ToCollege.net 源代码，我希望通过这种解析例子的方式能够帮助读者更快地领会如何去解决各种复杂的集成问题。 GWT 方面，我觉得难点之一是如何把完整的应用划分为可复用的组件。书中解析了拥有 1 万 5 千代码的 ToCollege.net 项目的源代码。我希望这本书能够帮助大家尽快掌握这项技术。至于 GWT，我觉得最棘手的难题之一是如何将您的应用划分为可重用的组件。关于这个问题，有各种各样的方式可以解决，也有很多互相针锋相对的建议。我觉得在自己动手实现之前，非常值得通过整个站点的上下文来了解别人是如何运用其中一种方式来解决这个问题的。

2.GWT 是用 Java 开发 Web2.0 应用的一种方式。在众多选择中，您为什么对它偏爱有加呢？

我第一个创业项目（MyHippocampus）是尝试开发一种通用存储工具，有点像《梦断代码》中的 Chandler，但我的项目中涉及更多的虚拟概念。首先，高度虚拟的是一个 Flash 程序，这部分我总觉得不太满意，我很讨厌实现 Flash 程序和 Java 服务器连接的那部分。之前我做过很多 Swing 方面的开发，所以对我来说 GWT 就非常自然，我尤其喜欢的是能够在客户和服务器端复用同一个对象。我不知道 GWT 是不是也会支持那些我放弃了但却正蒸蒸日上的类似 flash 类型的 UI。

3. GWT1.5 是最近发布的，而您的书也正是基于这个 1.5 版本之上。在您看来，这个新版本中加入的最有价值的特性是什么？

我觉得对于这个问题，答案是随着时间而变化的。最初，GWT1.5 只是为了迁移到 Java1.5 的使用上来。但现在我们所得到的则是一个令人惊喜的发布。编译器优化程度令人震惊。GWT 缔造了一个神话，让您的程序不需要修改任何代码都能在 GWT 编译器优化的帮助下运行得越来越快。您可以参考 Ray Cromwell 的一个关于 GWT Extreme 的出色的演讲—— http://timepedia.blogspot.com/2008/06/google-io-gwt- extreme-presentation.html，从中可以了解到它所带来的影响。 ImageBundles 不是一个全新的概念，但一旦您尝试使用这个特性，会完全为它所折服。30 个图像永远缓存在单一 HTTP 中而不给您添加任何负担？的确。1.5 中，由于注释支持的关系，这些缓存对象会被清理掉，但在孵化器中有一些优秀的代码能够帮助您把 ImageBundles 的概念延伸到其它类型的资源缓存上。

4. 您书中有一章特别解释了怎样针对搜索引擎来优化 GWT 站点。将 Ajax 应用变得可以被搜索这个需求很多时候都会被忽略或者无法正确实现。对于使用 GWT 创建 Web 应用的开发者来说，您觉得充分利用各种工具箱以及 Web2.0 功能的过程中，什么是最需要注意的？

显然，SEO 是一些应用必须具备的特性，而这项特性在富应用中又很难实现。我觉得，ToCollege.net 解决方案刚好是一种把 RIA 应用向搜索引擎敞开怀抱的轻量、不易入侵的方式。书中另外提到的一个主要概念是我常用的 command pattern 的使用。这是一个循环主题，我因此能够使用同一个结构来避免 XSRF 攻击 ; 实现与 Hibernate 的集成 ; 向客户端添加缓存，还能够很自然地让您的站点通过 Google Gears 在离线状态下同样正常工作。最后，本书还花了很多时间来讲安全，这也是我们非常注重的一个话题。

5. 有人曾对 GWT 及其自动生成代码的功能进行抨击，说如果通过一种语言（Java）来编写另一种语言 (JavaScript）的程序的话，会失去目标语言（JavaScript）的所有优点。您对这种说法是怎么看的？

这个问题问得很好。老实说，在我刚开始研究怎样创建富 Web2.0 应用的时候，我对 JavaScript 不是非常了解。一想到要编写大量针对浏览器的代码，要面对 IE6 的 bug，我就毛毛骨悚然。最近一段时间以来，我在 PatientsLikeMe 工作中用 JavaScript 编写了大量代码，不得不说的是 JavaScript 世界比我最初想象的要好很多。时间加上开放的头脑，您完全可以写出干净利落的 JavaScript 代码，只需要花点时间好好研究一下最佳用法。JavaScript 这门语言很有意思，但如果您只是试图通过写 JavaScript 来生成 Java，那您肯定会对它深恶痛绝。对于优秀的开发人员来说，JavaScript 可以起到非常好的作用，但仍然局限在一定程度以内。 GWT 诞生的原因是，Google 发现 JavaScript 不适合大型项目。他们有大量最优秀的开发人员，遵循最佳用法的原则进行开发，但项目很大的时候，他们发现外部工具的支持开始比干净的 JavaScript 代码更胜一筹。我觉得在考虑使用 GWT 的时候，牢记这点是非常有用的。GWT 不是为初级开发人员创建的 EZ-AJAX，也不是为那些不想学 JavaScript 的人而设计的，而是 Google 的天才开发人员在为开发更大型的富网络应用而抓狂的时候所激发的点子。

6. 很多使用 GWT 的开发人员都极为赞赏的一点是他们因此不需要再亲自验证应用在各种浏览器下的运行情况。您觉得这是 GWT 强有力的优势吗？

不见得。正如我之前提到的，在我开始运用 GWT 的时候，这是个非常引人注目的卖点，但是说实话，我觉得有点过高估计了这个问题。从这个角度来说，GWT 的确很好用，但一些 JavaScript 解决方案也不见得很烂。您可以找到很多相关的例子或者开发框架。当然，有时候您需要考虑把元素放在 popup 后面，这样 form 元素就不会混淆其中，当然您应该考虑一些关于漏洞的问题，但通常来说，跨浏览器开发中真正的难题是 CSS，而不是 JavaScript。 Prototype/JQuery/etc 是不错的类库。所以从这点来看，GWT 非常不错，但我不希望大家用 GWT 来跑一些非常基础、只需要几行 Script.aculo.us 的东西。如果您只是构架一个简单的网站，那使用 GWT 就可能有点小题大作了。

7. 在 GWT 生成 JavaScript 文件之后，您还常常需要在各种浏览器下 debug 您的应用程序吗? 如果要那样 debug 的话，您觉得容易找到并修正 bug 吗？

从 1.3 起，我就没必要在浏览器下 debug 那些生成的 JavaScript 了，即使有时候有 bug，95％都是我的错。GWT 生成的代码都很对。实际上，还不止这些。GWT 还能省去大量内存问题，甚至还能修补 JavaScript 开发人员的疏忽。GWT 能够在您毫无之觉的情况下修补一些漏洞。 CSS 完全是另外一码事。关于 CSS，我最后要做的都只是编译而已。我的基本工作流是，先在 hosted 模式下实现功能项，然后就只是等待几秒钟的代码刷新时间。然后编译，再在 Firefox 下查看，选用 Firefox 是因为因此可以借用 Firebug 的力量来查看 CSS 是否正确。再然后，把 CSS 迁回到项目中来，查看要让该 CSS 在 IE 下正常显示还需要做些什么。但是，很长一段时间以来，我都没有必要再把生成的 JavaScript 以 pretty 模式输出。

8. 很多人认为，像 GWT 这样自动生成代码或者精细的 JavaScript 开发框架的出现意味着传统的“Web 平台”已经发展到了它的极点，应该由一些更先进的事物来替代了。您对这个观点怎么看？

这正是问题所在！我认同这个观点。这个观点很有意思，但也带着些讥讽。我觉得自己对 REST 不断增长中的热情实际上也使得我越来越感到 web 平台实际上在拖大家的后腿。REST 用起来也很好，但我常常觉得它应该在那些服务器只负责 REST 服务，而客户端负责与 UI 相关的一切事务的世界里会运行得更好。客户端越“富有”，两端就越难覆写所需功能项，把应用逻辑布置在服务器端就愈发显的奇怪。InfoQ 关于 SOFEA 和 ThinServerArchitecture 的文章在这点上着实影响了我的看法。我觉得 GWT 在下面这个情景中运用会非常恰当。比方说，您有一个可以在客户和服务器两端运行的代码库，然后您可以把 MVC 栈从服务器端转移到客户端，这对于应用的可伸缩性以及用户体验都非常有帮助。但问题的本质是，我们是否需要引进新事物。我觉得还没有这个必要。我们有可能正在接近将应用逻辑布置在服务器端的末期，不仅仅将浏览器作为用户代理。浏览器的应用无处不在，而 GWT 帮助您解决很多相关问题，除此之外，您还能从 Google Gears 中受益。最后，如果您还想要实现更多，那么 Java WebStart 是不错的选择。

9. 作为 GWT 工具箱的用户，您期望它将来的发布中引入一些怎样的新特性？

你想知道我的“白日梦”吗？我很希望 GWT 能够在动态语言中使用。当然我也知道，这也可能意味着失去极好的 refactoring 支持以及 GWT 为比较大的团队提供的其它一些优点。但开发 GUI 的人们强烈期盼对动态语言的支持。如果能够在 GWT 项目的一些较为动态的元素上混合使用 Groovy，那多有意思阿！

阅读英文原文： Interview and Book Excerpt: Pro Web 2.0 Application Development with GWT 。

志愿参与 InfoQ 中文站内容建设，请邮件至 editors@cn.infoq.com 。也欢迎大家到 InfoQ 中文站用户讨论组参与我们的线上讨论。