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 代码
  1. public static Object getGWTService(Class service, String ServiceURI) {
  2. Object instance = GWT.create(service);
  3. ServiceDefTarget target = (ServiceDefTarget) instance;
  4. target.setServiceEntryPoint(GWT.getModuleBaseURL() + ServiceURI);
  5. return instance;
  6. }
     

这种方式是行不通的，我尝试了很久希望能够通过统一的接口来获得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到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>