GWT项目经验总结与感想

最近接手了一个GWT的项目，因为公司从来就没有做过这个技术的项目，所以我必须负责所有的关于GWT的Research以及Design的工作。我很早以前就对于Google那帮天才所作的OpenSource项目非常感兴趣了，可惜一直没有机会接触，这次要我从头学起GWT，我当然是乐在其中咯。不过也因为是从头学起所以走了许许多多弯路！在这篇文章中我就和大家分享一下我的GWT项目经验与感想。

GWT编程经验总结（GWT客户端的限制）

• GWT 客户机代码必须与 Java 1.4 兼容。那意味着别指望在GWT client-side里使用类属性(<t>泛型)、新样式的 for 循环等等5.0的新特征。</t>
• 在GWT客户端中只有极少的 Java 标准库受到支持。受支持的库类限于 java.util 包和 java.lang 包。但并不是所有这些包都支持。举例来说Java.lang.reflect 包就不被支持（无法使用Proxy, Method等功能）。也就是说Java的反射机制在GWT的客户端中是不会通过编译的。（其实很容易考虑，你只要想想Javascript有没有这个功能。因为所有的Client-side的Java代码都将编译成Javascript）
• 对于序列化的客户机类也有一些限制，Java的Serialization是不被支持的。该类可以通过实现接口com.google.gwt.user.client.rpc.IsSerializable来实现。所有JavaBean必须继承GWT的序列化接口。(实现客户端与服务器端之间的JavaBean交互数据)
• 因为 JavaScript 语言是不支持线程。所以在GWT 编译程序中会忽略 synchronized 声明。当然，多线程的使用也别指望了。
• Object.getClass().getName() 也是不支持的。要使用GWT.getTypeName(Object)才可以得到对象类型。
• GWT允许自定义Java-Javascript编译器，如果你有兴趣可以研究一下。反正作到现在我觉得没那个必要。
  
• 支持自定义控件库。做过J2EE客户端的朋友一定有这样的经验，喜欢把所有的taglib放入一个单独的project中。从而实现一个公司内部的taglib 库，在以后的项目中我们可以重用这些taglib. GWT其实也可以这样的。但是你需要定义一个控件库的*.gwt.xml。并且在你的GWT项目的*.gwt.xml 中inherits。
• 不可能将所有的服务器端接口合并为一个Factory，
  Example:
  
  java 代码

  public static Object getGWTService(Class service, String ServiceURI) {
           Object instance = GWT.create(service);
           ServiceDefTarget target = (ServiceDefTarget) instance;
           target.setServiceEntryPoint(GWT.getModuleBaseURL() + ServiceURI);
           return instance;
  }

这种方式是行不通的，我尝试了很久希望能够通过统一的接口来获得RPC Service，可是当编译Java to Javascript时会报出Only class literals may be used as arguments to GWT.create()的Error message, 我的理解就是GWT.create(..)中的参数不可以申明为一个变量的interface class.可能在转换为Javascript时会出错。具体如何的内部机制无从考证。（这个GWT做得我都想哭了，我喜欢的设计方式都这样莫名其妙的被抹杀了）

总之，以上为GWT客户端的限制，虽然有些麻烦，但是由于GWT客户端编译时要进行Java到Javascript之间的转换的原因，避免了你去开发那更烦人Javascript。而且这样一来可是使得客户端，服务器端的层次变得更清晰。因为我们无法把大量的逻辑代码写入客户端。层次的明晰使得维护，测试变得简便。总而言之，只要在客户端开发时注意我以上提到的这些注意事项，把大量的逻辑代码放入服务器端，你会发现其实GWT还是不错的！

参考：http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.JavaToJavaScriptCompiler.LanguageSupport.html

整合IOC和GWT

用过GWT的朋友一定知道，要在GWT 中定义一个Remote service就必须在*.gwt.xml中定义这样一段servlet声明。
<servlet path="/serviceURI " class="com.maqujun.too.handsome.ServiceImpl"></servlet>可是这样的定义灵活性不够，而且无法做到将外部的Java file定义为Servlet
项目中我们会希望使用IOC工具来实现Remote service的申明。并且实现把所有Service定义为外部Jar（方便逻辑层的Junit测试）。这种方法不同于标准的GWT开发的，在此不是要提倡，只是提出另一种实现的方式而已。
我在我的项目中就使用了IOC和GWT的整合。我要让GWT整合我公司内部开发的IOC工具，而且还要整合Spring和Hivemind.这些流行的IOC工具（痛苦的过程），这里就不一一举例了。不过我要提一下Spring和GWT的整合。通过Spring 的DispatcherServlet来分配Server-side RPC servlet.这样简单就整合了这两个框架。怎么让那些老外想出来的？太有才了。有研究这方面内容的朋友可以参考dengyin2000的这篇文章http://www.iteye.com/topic/58084 。这里就不重复了。感谢dengyin2000的技术分享。官方网站是：http://gwt-widget.sourceforge.net/?q=node/39 <o:p></o:p>

部署GWT到Tomcat中<o:p></o:p>

在我研究GWT时，看到很多网站都有人提问如何在Tomcat中部署GWT 。其实使用Ant打包GWT成一个war file再放入Tomcat中就可以了。我把我GWTTest项目中的build.xml文件发出来，有需要的朋友可以下载看一下，xml内有详细的注释。只要把XML中我打”*”号的部分改为你的GWT项目中相应的内容就可以直接使用Ant打包您的GWT project成war 文件了。

Echo和GWT

网上已经有非常详细的文章来比较这两个 AJAX框架了。这里就不重复了，有兴趣的朋友可以google一下。我之前也做过一个Echo2的项目，并且写了一篇Echo2的分析文章来介绍Echo2。我这里就从一个开发人员的角度来简单的分析一下这两框架。其实从根本的底层技术上来讲，两者根本就没有可比性。GWT是把客户端Java 代码转换为JAVASCRIPT，再使用RPC调用服务器端逻辑层Servlet。而Echo2应该就是建立在Servlet上的一个框架，具体的核心实现方式我不了解。不过这两种技术都有一个共同点——太有才了。都是全ajax的web框架，而且你基本不用理那烦人的JAVASCRIPT。视图层使用类似于javascript的Java编写方式就是最大的一个创新。从我个人的角度来说我更倾向于GWT，因为Echo的性能实在有些不敢恭维(不过我相信如果未来的Echo3能够提升性能的话，Echo会变得更出色)。<o:p></o:p>

看了一些Javaeye中其他关于GWT的文章。感到很多人是因为GWT有太多有别于一般意义上的java语言的特性才对GWT产生了一些误解。抱歉，我这里不是在针对谁，毕竟我相信除了Google之外很少会有公司运用这个框架来开发项目。很多技术如果不是在实际项目中运用，仅凭自学是很难深入了解的。当然我并不是说GWT有多好，他也有局限性。坦率说我更喜欢wicket，个人觉得他融入了部分的GWT的客户端开发创意，而且很好的弥补了GWT中的一些不足之处。我喜欢这些有创意的开发理念，不断涌现的新创意会让Java这一技术更有意思。<o:p></o:p>

评论

10 楼 ddmm2ddmm 2008-07-24  

好贴 留爪

9 楼 wangtiantian5566 2008-06-24  

Spring和GWT整合是完全分开的,只是从Spring哪端传过来的数据要在GWT端进行一下转换,不过也很方便的.以前GWT不支持Serializable ,GWT client  端Models要实现IsSerializable 接口,现在GWT发布了1.5不用实现这个接口了..
可方便调用了.

8 楼 maqujun 2007-11-27  

aibozeng 写道

（1） 可以的。但不能通过 web.xml去 启动 Spring。自己写一个 SpringFactory，去加载 Spring . 我测试过的。

（2） 如果你改写GWT提供的 RemoteServiceServlet ，还能省去 写 每一个Servlet，GWT前端直接调用 Spring 管理的Bean .

其实Spring和GWT整合可以分两种：
1）局部整合，就像楼上说的单独把Spring内容定义在GWT RPC内部。这种方法和平时使用Spring没什么两样。
2）完全整合，就像我上文中提到的直接通过Spring 的DispatcherServlet来分配Server-side RPC servlet。而无需定义Servlet在GWT.xml中。通过web.xml启动时加载spring xml。使用第三方架包gwt-servlet-Library.jar来实现(http://gwt-widget.sourceforge.net/?q=node/38)

7 楼 aibozeng 2007-11-26  

（1） 可以的。但不能通过 web.xml去 启动 Spring。自己写一个 SpringFactory，去加载 Spring . 我测试过的。

（2） 如果你改写GWT提供的 RemoteServiceServlet ，还能省去 写 每一个Servlet，GWT前端直接调用 Spring 管理的Bean .

6 楼 jiwenke 2007-11-26  

在测试GWT RPC + SpringMVC的时候，不能够在Host模式下进行，GWTShell找不到Spring.jar，所以每次我都要把这些测试放到web模式下去进行，这样觉得很麻烦。
不知道有没有好的解决方法？可以在HOST模式下就能测试GWT RPC + SpringMVC？

5 楼 jiwenke 2007-11-26  

在测试GWT RPC + SpringMVC的时候，不能够在Host模式下进行，GWTShell找不到Spring.jar，所以每次我都要把这些测试放到web模式下去进行，这样觉得很麻烦。
不知道有没有好的解决方法？可以在HOST模式下就能测试GWT RPC + SpringMVC？

4 楼 aibozeng 2007-11-17  

jiwenke 写道

写的很好啊，用GWT做应用的时候，虽然是JAVA语言，但是却和一般的JAVA语言开发有很多不同。因为是要把这些JAVA Code用GWTCompiler转化成JavaScript代码的。但是这点的理解上让自己出了很多问题。
有空一起探讨啊，个人很喜欢这个框架 ：）

  我个人在项目中使用了快一年了，非常喜欢她。

  看了 liferay 的 demo ，觉得 如果现在的 Portal容器展现的 Portlet 窗口 使用 AJAX 和 DIV 技术 ，最大、最小、移动、执行等功能的速度就不一样了。如果 Portlet 里的 业务功能 也是 以 AJAX 来 局部刷新， 那 速度 就 更快了。
  
   所以 ，我们 应该 使用 GWT 来 开发 Portal的 portlet 展现 。
 

 

3 楼 maqujun 2007-11-15  

benbenbin 写道

感谢楼主的分享!
不过下面这一段怎么少字了呀?描述不全...希望楼主补上. Thanks in advance!

谢谢你的回复，我是在word里面写的这篇文章，但是当我复制到javaeye里却有很多文字都无法显示出来。我已经改了很多地方了。谢谢你的提醒，我会尽快补上缺损的部分的。

2 楼 jiwenke 2007-11-15  

写的很好啊，用GWT做应用的时候，虽然是JAVA语言，但是却和一般的JAVA语言开发有很多不同。因为是要把这些JAVA Code用GWTCompiler转化成JavaScript代码的。但是这点的理解上让自己出了很多问题。
有空一起探讨啊，个人很喜欢这个框架 ：）

1 楼 benbenbin 2007-11-13  

感谢楼主的分享!

不过下面这一段怎么少字了呀?描述不全...希望楼主补上. Thanks in advance!

引用

Echo和GWT

     网上已经有非常详细的文章来比较这两个 AJAX框架了。这里就不重复了，有兴趣的朋友可以google一下。我之前也做过一个Echo2的项目，并且写了一篇的分析文章来介绍Echo2。我这里就从一个开发人员的角度来简单的分析一下这两框架。其实从根本的底层技术上来讲，两者根本就没有可比性。是把客户端代码转换为，再使用调用服务器端逻辑层。而应该就是建立在上的一个框架，具体的核心实现方式我不了解。不过这两种技术都有一个共同点——太有才了。都是全的框架，而且你基本不用理那烦人的。视图层使用类似于的编写方式就是最大的一个创新。从我个人的角度来说我更倾向于，因为的性能实在不敢恭维。



    看了一些Javaeye中其他关于GWT的文章。感到很多人是因为不会用才对GWT产生了一些误解。抱歉，我这里不是在针对谁，毕竟我相信除了Google之外很少会有公司运用这个框架来开发项目。很多技术如果不是在实际项目中运用，仅凭自学是很难深入了解的。当然我并不是说GWT有多好，他也有局限性。坦率说我更喜欢wicket，个人觉得他融入了部分的GWT的客户端开发创意，而且很好的弥补了GWT中的一些不足之处。我喜欢这些有创意的开发理念，不断涌现的新创意会让Java这一技术更有意思。