GWT开发的8个忠告
Google Web工具包（GWT）确实是使用Java开发Ajax应用的一种诱人方法。如果你在AWT/Swing/SWT和服务器小程序方面有着扎实背景，实际上很容易学会使用GWT，但如果要做的不仅仅是快速原型设计，那么某些难题仍然存在。
忠告之一: 分而治之
众所周知，GWT应用就是Java应用。不过，问题在于是“哪种Java”，我们需要牢记: GWT编译的是与J2SE 1.4.2或者更早版本兼容的Java源代码。另外，只有J2SE 1.4.2 API的子集得到支持，即java.lang和java.util程序包。即便在使用这些程序包时，也要非常认真地研究Google在运行库支持方面的注释，并且牢记相应的忠告: 如果确保从一开始就只使用客户端代码中的可转换类，那么就可以避免许多问题。为了及早发现问题，只要在宿主模式（hosted mode）下运行，就要对照JRE仿真库检验代码。因而，第一次运行应用时，就会发现大部分不支持的库。所以，要及早并且经常运行。
现在，笔者给出的忠告就是“分而治之”，具体意思就是一开始就把应用代码分成三个不同的部分: 客户端代码、RPC相关代码和服务器端代码，然后构建相应的Eclipse项目，从而完成任务。这样一来，就可以利用不同的Java语言版本，用于客户端和服务器部分。笔者用Java 5构建了应用的服务器部分（服务器小程序代码）; 但如果使用Mustang版本，那么在本文的代码片段中（由于篇幅有限，本文所涉及的程序代码可通过以下链接查询: http://blog.ccw.com.cn/article-htm-itemid-17924-type-blog.html），可以用Java 6取代Java 5。即便在服务器端仍然使用J2SE 1.4.2，这种分治法也可以在将来提供更大的灵活性，明确分离代码（“分离问题”），而不会在GWT宿主模式下限制调试操作。如果所有部分都在一个Eclipse项目中，则需要非常严谨，特别是在服务器端上; 不然，就会出现编译或者运行问题。
需要使用特殊的命名约定，这样可以清楚确认不同项目，并且简化部署脚本。可以使用譬如名为GWT-< ModuleName>的Eclipse工作集来包括所有三个项目。这里，“ModuleName”是识别Web应用的GWT模块的名称。
● 客户端代码: 包含与用户界面相关的代码，可以转换成JavaScript。因此，局限于J2SE 1.4.2和GWT运行时支持。启用每个项目的Eclipse Java编译器设置和“Java编译器错误/警告”，把Java依从级别调整到1.4、把源代码和类文件兼容性调整到1.4（假设不是使用1.4之前的JDK版本）。该项目的名称是< ModuleName>-client，譬如“JUnit2MR-client”，它依赖于构建路径设置中的< ModuleName>-rpc项目。程序包名称类似< com.company.project>.gwt.< moduleName>.client。
● RPC相关代码: 包含RPC相关的代码，可以转换成JavaScript。该项目遵从与上述客户端代码项目同样的指导准则。项目名是< ModuleName>-rpc，譬如“JUnit2MR-rpc”，它并不依赖于其他任何项目。程序包名称与< ModuleName>-client项目的程序包名称一样。RPC项目包含客户端上的远程接口、RPC期间由GWT进行序列化的数据传输对象，以及全局常量类。
● 服务器端代码: 含有服务器小程序代码，如果服务器端由Java服务器小程序组成的话。如果使用Tomcat 5.5或者Tomcat 6，可以充分利用Java 5+的全部功能。启用每个项目的Eclipse编译器设置，然后使用Java 5编译器设置，依从级别设置为5.0。如果使用Eclipse 3.2.2，那么其新的“源代码→清理”特性也值得配置。该项目名称是< ModuleName>-server，譬如“JUnit2MR-server”，它依赖于构建路径设置中的< ModuleName>-rpc项目。如果按照GWT的默认程序包提案进行编程，程序包名称是< com.company.project>.gwt.< moduleName>.server。
忠告之二: 调试和错误报告不仅仅只有Window.alert ()
在创建GWT应用时，其实可以使用IDE的全部调试功能。但在深入分析何处可能出现错误之前，需要代码的客户端和服务器端都有可靠的异常报告机制。使用try/catch代码块通常可以做到这一点。在客户端的catch代码块中，应当注意这一现实: 默认的方法调用e.printStackTrace()并不是在所有情况下都适合的解决办法。它适用于应用运行在GWT宿主模式下，把文本输出到Eclipse控制台。不过在Web模式下，要问问自己: “我发送到stdout或者stderr的堆栈跟踪信息和错误信息会在什么地方显示？”一种可能的解决方法就是使用Mat Gessel的调试实用程序类（http://www.asquare.net/gwttk），但是需要浏览器JavaScript控制台来查看Web模式下的结果。
在客户端，建议要做的一件事就是，使用GWT.setUncaughtExceptionHandler()方法，为任何未被发现的异常提供自己的异常处理程序。发现了这几种异常后，有几个选择: GWT.log（message, caught）、Debug.println (message_with_stacktrace); 如果使用Mat Gessel的Debug类，可选择Window.alert（message_with_stacktrace），或者自己定制的错误报告。
视来源而定，会得到“无法装入模块”或者“未被发现的异常被漏过”的信息。笔者编写了一个小小的DebugUtility类，它提供了易于定制的默认客户端错误处理机制（见代码片段1）。
在服务器端，可以使用java.util.logging API或者log4j的广泛功能，具体取决于个人偏好或者项目的约束条件。但要是没有为GWT的com.google.gwt.user.server.rpc.RemoteServiceServlet类打补丁，对于未被发现、未被检查的异常，只会在堆栈跟踪里面得到提示，指向生成该错误的服务器端类。对于catch()代码块里面发现及报告的被检查的异常，一切都正常。
忠告之三: 当心GWT Shell的“刷新”按钮陷阱
在宿主模式下启动应用时，会在浏览器任务栏上看到“刷新”按钮。要是摁了这个按钮，GWT就会把修改过的Java客户端源代码重新编译成Java字节码（作为.gwt.-cache/bytecode目录中的.tmp文件），然后重新装入模块。可以使用这个按钮来缩短编辑→编译→调试周期，但在使用这项特性时要牢记几个方面:
● 只有修改过的源代码才重新编译，也就是说，不会为依赖修改过代码的文件生成新的字节码。所以，如果改变了全局常量的值，假设public final int字段的值，不会立即在相关文件看到这个变化。
● 只有修改过的源代码才由GWT重新编译。这意味着，即便Eclipse IDE里面的“Project clean”也帮不上忙; 要影响到所有的相关源代码，譬如通过添加新的空行。
因为这个过程相当笨拙，笔者的忠告是在修改全局常量时遵循以下四个步骤:
1．在相应的源文件里面改变public final constant值;
2．重新编译改变后的源代码;
3．移除整个< ModuleName>-client/.get-cache/bytecode目录，从而删除GWT缓存内容;
4、使用Eclipse里面的“Run as”，重新开始启动应用，从而创建带重新编译后字符码的新GWT缓存内容，这种情况下，最好忽视“刷新”按钮，不过在有些情况下，删除整个< ModuleName>-client/.get-cache/bytecode目录后可以使用“刷新”按钮。
在修改服务器端代码时，GWT字节码缓存内容不受影响。不过，嵌入的Tomcat实例会缓存它，因而在使用“刷新”按钮后，只有重新开始启动应用后最初改变的代码才会得到认可。所以为了安全起见，改变服务器端代码后，最好还是重新开始启动应用。
忠告之四: 在宿主模式下读取Servlet Init参数
在处理数据库系统时，一般不希望服务器小程序源代码中有硬编码的数据库连接参数。通常会从属性文件读取这些参数; 或者更好的是，把它们作为init参数提供给服务器小程序（作为应用的Web.xml文件的一部分）。如果在Web模式下运行应用那没有什么，但在宿主模式下会出问题，这是由于GWT宿主模式下的服务器小程序处理存在限制。
好消息是，只要修改由嵌入式Tomcat实例使用的Web.xml文件，就可以解决这个问题。为此，修改< ModuleName>-client/tomcat/webapps/ROOT/WEB-INF目录中的Web.xml文件（或者必要时创建一个）: 除了嵌入式Tomcat的GWTShellServlet映射外，添加带有init参数的上下文部分。因为上下文信息是“全局性的”，而不是针对特定的服务器小程序，在这里只有一部分的init参数信息，或者使用特殊的命名方案，把参数与不同的服务器小程序联系起来。如果使用这个新的web.xml文件，可以删除src/web/WEB-INF文件夹中的那个旧文件。
在服务器小程序代码中，访问init参数的方式与Web模式下读取它们的方式一样，譬如final String host = getInitParameter("host")。笔者实现这一点的办法就是修改GWT的RemoteServiceServlet，方法跟第二个忠告里面的如出一辙。现在，只要覆盖GenericServlet的getInitParameter()方法，以便使用getServletContext()，而不是 getServletConfig()。
另一个忠告是，如果在宿主模式下和Web模式下测试不同的服务器代码，略过Gant脚本中的GWT编译部分，从“temp”位置拷贝编译前的JavaScript代码，则可以节省时间。这适用于客户端代码复杂、编译时间超过10分钟的情形。
忠告之五: 在浏览器里面显示PDF文件
大多数实际的Web应用提供了生成及阅读PDF文件的方法。本文假设这个PDF文件由服务器小程序生成，譬如通过JasperReport。以后只要点击某个超文本链接，就可以在浏览器里面阅读生成的文件。如果想在宿主模式下和Web模式下测试这项特性，建议采取以下步骤:
1．设计一个RPC接口，接受告诉服务器是在宿主模式下运行还是在Web模式下运行的布尔参数。接口方法会返回的字符串应当带有服务器小程序生成的PDF文件的名称（即文件名的最后一部分）。
2．根据代码片段4显示的代码，实现服务器小程序代码，这取决于布尔参数“isScript”。
3．在客户端: 在窗口组件代码里面，使用GWT.isScript()参数调用createXyzPDF()方法，从而生成包含服务器小程序结果字符串的外部超文本链接。
代码片段4显示了接口方法名为createSummaryPDF()的示例。从服务器小程序返回的字符串是“summary.pdf”。
这当然不是处理这种情况的惟一办法，但目前适用于我们这个示例。请注意: 在宿主模式下启动应用之前，必须在< ModuleName>-client project's src/…/public文件夹中至少创建一个虚假的“summary.pdf”文件（文件名从服务器小程序返回）。不然，在浏览器中点击了超文本链接后，GWT试图读取PDF文件时，会出现“HTTP 404－找不到网页”的信息。
忠告之六:力求获得无状态服务器
设计客户机/服务器Web应用时要考虑的一个关键问题就是: 如何处理会话和状态管理？在Web 1.0时代，答案很显然: 会话和状态管理是一个服务器问题。但若使用GWT，就有另一个选择。服务器再也不是只提供HTML内容的“web”服务。使用GWT RPC，服务器现在可以支持只提供结构化数据的服务———在本文示例中，服务由服务器小程序实现。
那么，GWT对会话和状态管理有何影响呢？GWT的技术领导Bruce Johnson在去年的JAOO大会上指出，若使用GWT，会话管理现在应当是一个客户端问题。附图显示的幻灯片评述了种种变化。
在本文的JUnit2MR GWT应用中，笔者一开始使用传统方法来处理服务器小程序中的会话状态。但这是相当笨拙的任务，于是寻找另一种选择。因此，看了Bruce的幻灯片后，决定重新设计整个应用。但这一步需要改变所有RPC接口、缓存策略; 最重要的是，还要改变所有的服务器小程序。因此笔者的建议是: 及早考虑在何处实施会话和状态管理，不妨试试Bruce Johnson的诀窍。最终会收到成效。
由于这个决定，客户端对象之间有了更多的联系。于是笔者使用了有名的GoF中介者模式（mediator pattern）。不过，在客户端有一些JDK 1.4和GWT运行库的限制。因此，重新实现了PropertyChangeEvent类和中介者支持，来处理监听程序注册和消息广播。
忠告之七: 使用Selenium实现GWT Web测试的自动化
Selenium是一种开源工具，它能够轻松测试包含丰富、互动的客户端内容的Web应用。 所以，它非常适用于测试像用GWT创建的应用那样的Ajax应用。
当然，GWT里面仍有JUnit和JUnit支持功能，特别是针对系统的异步部分。这里着重介绍Selenium，因为它易于使用（至少它的IDE是这样）、功能强大。最后但并非最不重要的一点是，它与JUnit有许多共同之处。可以使用Selenium IDE来记录GUI用例，然后使用其“Play”特性来运行记录下来的操作。每个操作之后跟着类似JUnit的“assert”命令，负责确认页面上的某些文本。该IDE是Firefox的扩展插件，但务必要使用最新版本的Selenium: Selenium IDE 0 .8 .7，因为它包含了“waitFor…”命令的重大修正版。说到测试Ajax应用，这些命令以及“pause”命令非常重要。
忠告之八: 使用Groovy Gant脚本部署应用
在GWT宿主模式下试运行应用，这确实很好，但把应用部署到应用服务器上或者类似Tomcat的服务器小程序容器上，GWT的真实功能才会体现出来。在这一步，需要创建一个war文件，它会自动拷贝到Tomcat“webapps”目录。当然，可以使用Ant和ant-contrib进行所有必要的准备、编译、拷贝及其他任务。但由于Ant脚本变得更复杂后， ant-contrib控制结构和属性regex处理有一点笨拙。于是可以使用集Groovy和Ant两者之所长的Gant。安装Groovy和Gant用不了10分钟，然后，使用来自“build.properties”文件的普通属性，即可定制“build.gant”脚本。（小黑编译）
（计算机世界报 2007年6月25日 第24期 B22、B23）
忠告之一: 分而治之
众所周知，GWT应用就是Java应用。不过，问题在于是“哪种Java”，我们需要牢记: GWT编译的是与J2SE 1.4.2或者更早版本兼容的Java源代码。另外，只有J2SE 1.4.2 API的子集得到支持，即java.lang和java.util程序包。即便在使用这些程序包时，也要非常认真地研究Google在运行库支持方面的注释，并且牢记相应的忠告: 如果确保从一开始就只使用客户端代码中的可转换类，那么就可以避免许多问题。为了及早发现问题，只要在宿主模式（hosted mode）下运行，就要对照JRE仿真库检验代码。因而，第一次运行应用时，就会发现大部分不支持的库。所以，要及早并且经常运行。
现在，笔者给出的忠告就是“分而治之”，具体意思就是一开始就把应用代码分成三个不同的部分: 客户端代码、RPC相关代码和服务器端代码，然后构建相应的Eclipse项目，从而完成任务。这样一来，就可以利用不同的Java语言版本，用于客户端和服务器部分。笔者用Java 5构建了应用的服务器部分（服务器小程序代码）; 但如果使用Mustang版本，那么在本文的代码片段中（由于篇幅有限，本文所涉及的程序代码可通过以下链接查询: http://blog.ccw.com.cn/article-htm-itemid-17924-type-blog.html），可以用Java 6取代Java 5。即便在服务器端仍然使用J2SE 1.4.2，这种分治法也可以在将来提供更大的灵活性，明确分离代码（“分离问题”），而不会在GWT宿主模式下限制调试操作。如果所有部分都在一个Eclipse项目中，则需要非常严谨，特别是在服务器端上; 不然，就会出现编译或者运行问题。
需要使用特殊的命名约定，这样可以清楚确认不同项目，并且简化部署脚本。可以使用譬如名为GWT-< ModuleName>的Eclipse工作集来包括所有三个项目。这里，“ModuleName”是识别Web应用的GWT模块的名称。
● 客户端代码: 包含与用户界面相关的代码，可以转换成JavaScript。因此，局限于J2SE 1.4.2和GWT运行时支持。启用每个项目的Eclipse Java编译器设置和“Java编译器错误/警告”，把Java依从级别调整到1.4、把源代码和类文件兼容性调整到1.4（假设不是使用1.4之前的JDK版本）。该项目的名称是< ModuleName>-client，譬如“JUnit2MR-client”，它依赖于构建路径设置中的< ModuleName>-rpc项目。程序包名称类似< com.company.project>.gwt.< moduleName>.client。
● RPC相关代码: 包含RPC相关的代码，可以转换成JavaScript。该项目遵从与上述客户端代码项目同样的指导准则。项目名是< ModuleName>-rpc，譬如“JUnit2MR-rpc”，它并不依赖于其他任何项目。程序包名称与< ModuleName>-client项目的程序包名称一样。RPC项目包含客户端上的远程接口、RPC期间由GWT进行序列化的数据传输对象，以及全局常量类。
● 服务器端代码: 含有服务器小程序代码，如果服务器端由Java服务器小程序组成的话。如果使用Tomcat 5.5或者Tomcat 6，可以充分利用Java 5+的全部功能。启用每个项目的Eclipse编译器设置，然后使用Java 5编译器设置，依从级别设置为5.0。如果使用Eclipse 3.2.2，那么其新的“源代码→清理”特性也值得配置。该项目名称是< ModuleName>-server，譬如“JUnit2MR-server”，它依赖于构建路径设置中的< ModuleName>-rpc项目。如果按照GWT的默认程序包提案进行编程，程序包名称是< com.company.project>.gwt.< moduleName>.server。
忠告之二: 调试和错误报告不仅仅只有Window.alert ()
在创建GWT应用时，其实可以使用IDE的全部调试功能。但在深入分析何处可能出现错误之前，需要代码的客户端和服务器端都有可靠的异常报告机制。使用try/catch代码块通常可以做到这一点。在客户端的catch代码块中，应当注意这一现实: 默认的方法调用e.printStackTrace()并不是在所有情况下都适合的解决办法。它适用于应用运行在GWT宿主模式下，把文本输出到Eclipse控制台。不过在Web模式下，要问问自己: “我发送到stdout或者stderr的堆栈跟踪信息和错误信息会在什么地方显示？”一种可能的解决方法就是使用Mat Gessel的调试实用程序类（http://www.asquare.net/gwttk），但是需要浏览器JavaScript控制台来查看Web模式下的结果。
在客户端，建议要做的一件事就是，使用GWT.setUncaughtExceptionHandler()方法，为任何未被发现的异常提供自己的异常处理程序。发现了这几种异常后，有几个选择: GWT.log（message, caught）、Debug.println (message_with_stacktrace); 如果使用Mat Gessel的Debug类，可选择Window.alert（message_with_stacktrace），或者自己定制的错误报告。
视来源而定，会得到“无法装入模块”或者“未被发现的异常被漏过”的信息。笔者编写了一个小小的DebugUtility类，它提供了易于定制的默认客户端错误处理机制（见代码片段1）。
在服务器端，可以使用java.util.logging API或者log4j的广泛功能，具体取决于个人偏好或者项目的约束条件。但要是没有为GWT的com.google.gwt.user.server.rpc.RemoteServiceServlet类打补丁，对于未被发现、未被检查的异常，只会在堆栈跟踪里面得到提示，指向生成该错误的服务器端类。对于catch()代码块里面发现及报告的被检查的异常，一切都正常。
忠告之三: 当心GWT Shell的“刷新”按钮陷阱
在宿主模式下启动应用时，会在浏览器任务栏上看到“刷新”按钮。要是摁了这个按钮，GWT就会把修改过的Java客户端源代码重新编译成Java字节码（作为.gwt.-cache/bytecode目录中的.tmp文件），然后重新装入模块。可以使用这个按钮来缩短编辑→编译→调试周期，但在使用这项特性时要牢记几个方面:
● 只有修改过的源代码才重新编译，也就是说，不会为依赖修改过代码的文件生成新的字节码。所以，如果改变了全局常量的值，假设public final int字段的值，不会立即在相关文件看到这个变化。
● 只有修改过的源代码才由GWT重新编译。这意味着，即便Eclipse IDE里面的“Project clean”也帮不上忙; 要影响到所有的相关源代码，譬如通过添加新的空行。
因为这个过程相当笨拙，笔者的忠告是在修改全局常量时遵循以下四个步骤:
1．在相应的源文件里面改变public final constant值;
2．重新编译改变后的源代码;
3．移除整个< ModuleName>-client/.get-cache/bytecode目录，从而删除GWT缓存内容;
4、使用Eclipse里面的“Run as”，重新开始启动应用，从而创建带重新编译后字符码的新GWT缓存内容，这种情况下，最好忽视“刷新”按钮，不过在有些情况下，删除整个< ModuleName>-client/.get-cache/bytecode目录后可以使用“刷新”按钮。
在修改服务器端代码时，GWT字节码缓存内容不受影响。不过，嵌入的Tomcat实例会缓存它，因而在使用“刷新”按钮后，只有重新开始启动应用后最初改变的代码才会得到认可。所以为了安全起见，改变服务器端代码后，最好还是重新开始启动应用。
忠告之四: 在宿主模式下读取Servlet Init参数
在处理数据库系统时，一般不希望服务器小程序源代码中有硬编码的数据库连接参数。通常会从属性文件读取这些参数; 或者更好的是，把它们作为init参数提供给服务器小程序（作为应用的Web.xml文件的一部分）。如果在Web模式下运行应用那没有什么，但在宿主模式下会出问题，这是由于GWT宿主模式下的服务器小程序处理存在限制。
好消息是，只要修改由嵌入式Tomcat实例使用的Web.xml文件，就可以解决这个问题。为此，修改< ModuleName>-client/tomcat/webapps/ROOT/WEB-INF目录中的Web.xml文件（或者必要时创建一个）: 除了嵌入式Tomcat的GWTShellServlet映射外，添加带有init参数的上下文部分。因为上下文信息是“全局性的”，而不是针对特定的服务器小程序，在这里只有一部分的init参数信息，或者使用特殊的命名方案，把参数与不同的服务器小程序联系起来。如果使用这个新的web.xml文件，可以删除src/web/WEB-INF文件夹中的那个旧文件。
在服务器小程序代码中，访问init参数的方式与Web模式下读取它们的方式一样，譬如final String host = getInitParameter("host")。笔者实现这一点的办法就是修改GWT的RemoteServiceServlet，方法跟第二个忠告里面的如出一辙。现在，只要覆盖GenericServlet的getInitParameter()方法，以便使用getServletContext()，而不是 getServletConfig()。
另一个忠告是，如果在宿主模式下和Web模式下测试不同的服务器代码，略过Gant脚本中的GWT编译部分，从“temp”位置拷贝编译前的JavaScript代码，则可以节省时间。这适用于客户端代码复杂、编译时间超过10分钟的情形。
忠告之五: 在浏览器里面显示PDF文件
大多数实际的Web应用提供了生成及阅读PDF文件的方法。本文假设这个PDF文件由服务器小程序生成，譬如通过JasperReport。以后只要点击某个超文本链接，就可以在浏览器里面阅读生成的文件。如果想在宿主模式下和Web模式下测试这项特性，建议采取以下步骤:
1．设计一个RPC接口，接受告诉服务器是在宿主模式下运行还是在Web模式下运行的布尔参数。接口方法会返回的字符串应当带有服务器小程序生成的PDF文件的名称（即文件名的最后一部分）。
2．根据代码片段4显示的代码，实现服务器小程序代码，这取决于布尔参数“isScript”。
3．在客户端: 在窗口组件代码里面，使用GWT.isScript()参数调用createXyzPDF()方法，从而生成包含服务器小程序结果字符串的外部超文本链接。
代码片段4显示了接口方法名为createSummaryPDF()的示例。从服务器小程序返回的字符串是“summary.pdf”。
这当然不是处理这种情况的惟一办法，但目前适用于我们这个示例。请注意: 在宿主模式下启动应用之前，必须在< ModuleName>-client project's src/…/public文件夹中至少创建一个虚假的“summary.pdf”文件（文件名从服务器小程序返回）。不然，在浏览器中点击了超文本链接后，GWT试图读取PDF文件时，会出现“HTTP 404－找不到网页”的信息。
忠告之六:力求获得无状态服务器
设计客户机/服务器Web应用时要考虑的一个关键问题就是: 如何处理会话和状态管理？在Web 1.0时代，答案很显然: 会话和状态管理是一个服务器问题。但若使用GWT，就有另一个选择。服务器再也不是只提供HTML内容的“web”服务。使用GWT RPC，服务器现在可以支持只提供结构化数据的服务———在本文示例中，服务由服务器小程序实现。
那么，GWT对会话和状态管理有何影响呢？GWT的技术领导Bruce Johnson在去年的JAOO大会上指出，若使用GWT，会话管理现在应当是一个客户端问题。附图显示的幻灯片评述了种种变化。
在本文的JUnit2MR GWT应用中，笔者一开始使用传统方法来处理服务器小程序中的会话状态。但这是相当笨拙的任务，于是寻找另一种选择。因此，看了Bruce的幻灯片后，决定重新设计整个应用。但这一步需要改变所有RPC接口、缓存策略; 最重要的是，还要改变所有的服务器小程序。因此笔者的建议是: 及早考虑在何处实施会话和状态管理，不妨试试Bruce Johnson的诀窍。最终会收到成效。
由于这个决定，客户端对象之间有了更多的联系。于是笔者使用了有名的GoF中介者模式（mediator pattern）。不过，在客户端有一些JDK 1.4和GWT运行库的限制。因此，重新实现了PropertyChangeEvent类和中介者支持，来处理监听程序注册和消息广播。
忠告之七: 使用Selenium实现GWT Web测试的自动化
Selenium是一种开源工具，它能够轻松测试包含丰富、互动的客户端内容的Web应用。 所以，它非常适用于测试像用GWT创建的应用那样的Ajax应用。
当然，GWT里面仍有JUnit和JUnit支持功能，特别是针对系统的异步部分。这里着重介绍Selenium，因为它易于使用（至少它的IDE是这样）、功能强大。最后但并非最不重要的一点是，它与JUnit有许多共同之处。可以使用Selenium IDE来记录GUI用例，然后使用其“Play”特性来运行记录下来的操作。每个操作之后跟着类似JUnit的“assert”命令，负责确认页面上的某些文本。该IDE是Firefox的扩展插件，但务必要使用最新版本的Selenium: Selenium IDE 0 .8 .7，因为它包含了“waitFor…”命令的重大修正版。说到测试Ajax应用，这些命令以及“pause”命令非常重要。
忠告之八: 使用Groovy Gant脚本部署应用
在GWT宿主模式下试运行应用，这确实很好，但把应用部署到应用服务器上或者类似Tomcat的服务器小程序容器上，GWT的真实功能才会体现出来。在这一步，需要创建一个war文件，它会自动拷贝到Tomcat“webapps”目录。当然，可以使用Ant和ant-contrib进行所有必要的准备、编译、拷贝及其他任务。但由于Ant脚本变得更复杂后， ant-contrib控制结构和属性regex处理有一点笨拙。于是可以使用集Groovy和Ant两者之所长的Gant。安装Groovy和Gant用不了10分钟，然后，使用来自“build.properties”文件的普通属性，即可定制“build.gant”脚本。（小黑编译）
（计算机世界报 2007年6月25日 第24期 B22、B23）