GWT开发的8个忠告.docVIP

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版本，那么在本文的代码片段中（由于篇幅有限，本文所涉及的程序代码可通过以下链接查询: /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项目。程序包名称类似 ject.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的默认程序包提案进行编程，程序包名称是 ject.gwt. moduleName.server。 忠告之二: 调试和错误报告不仅仅只有Window.alert () 在创建GWT应用时，其实可以使用IDE的全部调试功能。但在深入分析何处可能出现错误之前，需要代码的客户端和服务器端都有可靠的异常报告机制。使用try/catch代码块通常可以做到这一点。在客户端的catch代码块中，应当注意这一现实: 默认的方法调用e.printStackTrace()并不是在所有情况下都适合的解决办法。它适用于应用运行在GWT宿主模式下，把文本输出到 Eclipse控制台。不过在Web模式下，要问问自己: “我发送到stdout或者stderr的堆栈跟