GoogleWeb工具包(GWT)确实是使用Java开发Ajax应用的一种诱人方法。如果你在AWT/Swing/SWT和服务器小程序方面有着扎实背景,实际上很容易学会使用GWT,但如果要做的不仅仅是快速原型设计,那么某些难题仍然存在。
 
忠告之一: 分而治之
众所周知,GWT应用就是Java应用。不过,问题在于是哪种Java”,我们需要牢记: GWT编译的是与J2SE 1.4.2或者更早版本兼容的Java源代码。另外,只有J2SE 1.4.2 API的子集得到支持,即java.langjava.util程序包。即便在使用这些程序包时,也要非常认真地研究Google在运行库支持方面的注 释,并且牢记相应的忠告: 如果确保从一开始就只使用客户端代码中的可转换类,那么就可以避免许多问题。为了及早发现问题,只要在宿主模式(hostedmode)下运行,就要对照 JRE仿真库检验代码。因而,第一次运行应用时,就会发现大部分不支持的库。所以,要及早并且经常运行。
现在,笔者给出的忠告就是分而治之,具体意思就是一开始就把应用代码分成三个不同的部分: 客户端代码、RPC相关代码和服务器端代码,然后构建相应的Eclipse项目,从而完成任务。这样一来,就可以利用不同的Java语言版本,用于客户端 和服务器部分。笔者用Java 5构建了应用的服务器部分(服务器小程序代码); 但如果使用Mustang版本,那么在本文的代码片段中(由于篇幅有限,本文所涉及的程序代码可通过以下链接查询: [url]http://blog.ccw.com.cn/article-htm-itemid-17924-type-blog.html[/url]), 可以用Java6取代Java 5。即便在服务器端仍然使用J2SE1.4.2,这种分治法也可以在将来提供更大的灵活性,明确分离代码(分离问题),而不会在GWT宿主模式下限制 调试操作。如果所有部分都在一个Eclipse项目中,则需要非常严谨,特别是在服务器端上; 不然,就会出现编译或者运行问题。
需要使用特殊的命名约定,这样可以清楚确认不同项目,并且简化部署脚本。可以使用譬如名为GWT-< ModuleName>Eclipse工作集来包括所有三个项目。这里,“ModuleName”是识别Web应用的GWT模块的名称。
1.客户端代码: 包含与用户界面相关的代码,可以转换成JavaScript。因此,局限于J2SE1.4.2GWT运行时支持。启用每个项目的EclipseJava 编译器设置和“Java编译器错误/警告,把Java依从级别调整到1.4、把源代码和类文件兼容性调整到1.4(假设不是使用1.4之前的JDK版 本)。该项目的名称是< ModuleName>-client,譬如“JUnit2MR-client”,它依赖于构建路径设置中的< ModuleName>-rpc项目。程序包名称类似< com.company.project>.gwt.< moduleName>.client
2.RPC相关代码:包含RPC相关的代码,可以转换成JavaScript。该项目遵从与上述客户端代码项目同样的指导准则。项目名是< ModuleName>-rpc,譬如“JUnit2MR-rpc”,它并不依赖于其他任何项目。程序包名称与< ModuleName>-client项目的程序包名称一样。RPC项目包含客户端上的远程接口、RPC期间由GWT进行序列化的数据传输对象,以 及全局常量类。
3.服务器端代码: 含有服务器小程序代码,如果服务器端由Java服务器小程序组成的话。如果使用Tomcat5.5或者Tomcat 6,可以充分利用Java 5+的全部功能。启用每个项目的Eclipse编译器设置,然后使用Java5编译器设置,依从级别设置为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的堆栈跟踪信息和错误信息会在什么地方显示?一种可能的解决方法就是使用MatGessel的调试实用程序类 ([url]http://www.asquare.net/gwttk[/url]),但是需要浏览器JavaScript控制台来查看Web模式下的 结果。
在客户端,建议要做的一件事就是,使用GWT.setUncaughtExceptionHandler()方法,为任何未被发现的异常提供自 己的异常处理程序。发现了这几种异常后,有几个选择: GWT.logmessage,caught)、Debug.println (message_with_stacktrace); 如果使用MatGesselDebug类,可选择Window.alertmessage_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文件),然后重新装入模块。可以使用这个按钮来缩 短编辑编译调试周期,但在使用这项特性时要牢记几个方面:
1.只有修改过的源代码才重新编译,也就是说,不会为依赖修改过代码的文件生成新的字节码。所以,如果改变了全局常量的值,假设public final int字段的值,不会立即在相关文件看到这个变化。
2.只有修改过的源代码才由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文件(或者必要时创建一个): 除了嵌入式TomcatGWTShellServlet映射外,添加带有init参数的上下文部分。因为上下文信息是全局性的,而不是针对特定的服 务器小程序,在这里只有一部分的init参数信息,或者使用特殊的命名方案,把参数与不同的服务器小程序联系起来。如果使用这个新的web.xml文件, 可以删除src/web/WEB-INF文件夹中的那个旧文件。
在服务器小程序代码中,访问init参数的方式与Web模式下读取它们的方式一样,譬如final String host =getInitParameter("host")。笔者实现这一点的办法就是修改GWTRemoteServiceServlet,方法跟第二个忠告 里面的如出一辙。现在,只要覆盖GenericServletgetInitParameter()方法,以便使用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,会话管理现在应当是一个客户端问题。附图显示的幻灯片评述了种种变化。
GWT开发的8个忠告_忠告
在本文的JUnit2MR GWT应用中,笔者一开始使用传统方法来处理服务器小程序中的会话状态。但这是相当笨拙的任务,于是寻找另一种选择。因此,看了Bruce的幻灯片后,决 定重新设计整个应用。但这一步需要改变所有RPC接口、缓存策略; 最重要的是,还要改变所有的服务器小程序。因此笔者的建议是: 及早考虑在何处实施会话和状态管理,不妨试试Bruce Johnson的诀窍。最终会收到成效。
由于这个决定,客户端对象之间有了更多的联系。于是笔者使用了有名的GoF中介者模式(mediator pattern)。不过,在客户端有一些JDK 1.4GWT运行库的限制。因此,重新实现了PropertyChangeEvent类和中介者支持,来处理监听程序注册和消息广播。
 
忠告之七: 使用Selenium实现GWT Web测试的自动化
Selenium是一种开源工具,它能够轻松测试包含丰富、互动的客户端内容的Web应用。 所以,它非常适用于测试像用GWT创建的应用那样的Ajax应用。
当然,GWT里面仍有JUnitJUnit支持功能,特别是针对系统的异步部分。这里着重介绍 Selenium,因为它易于使用(至少它的IDE是这样)、功能强大。最后但并非最不重要的一点是,它与JUnit有许多共同之处。可以使用 Selenium IDE来记录GUI用例,然后使用其“Play”特性来运行记录下来的操作。每个操作之后跟着类似JUnit“assert”命令,负责确认页面上的某 些文本。该IDEFirefox的扩展插件,但务必要使用最新版本的Selenium: Selenium IDE 0 .8 .7,因为它包含了“waitFor…”命令的重大修正版。说到测试Ajax应用,这些命令以及“pause”命令非常重要。
 
忠告之八: 使用Groovy Gant脚本部署应用
GWT宿主模式下试运行应用,这确实很好,但把应用部署到应用服务器上或者类似Tomcat的服务器小程序容器 上,GWT的真实功能才会体现出来。在这一步,需要创建一个war文件,它会自动拷贝到Tomcat“webapps”目录。当然,可以使用Ant ant-contrib进行所有必要的准备、编译、拷贝及其他任务。但由于Ant脚本变得更复杂后, ant-contrib控制结构和属性regex处理有一点笨拙。于是可以使用集GroovyAnt两者之所长的Gant。安装GroovyGant 用不了10分钟,然后,使用来自“build.properties”文件的普通属性,即可定制“build.gant”脚本。