GWT项目经验总结与感想
GWT编程经验总结(GWT客户端的限制)
- GWT 客户机代码必须与 Java 1.4 兼容。那意味着别指望在GWT client-side里使用类属性( 泛型) 、新样式的 for 循环等等5.0 的新特征。
- 在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还是不错的!
整合IOC和GWT
可是这样的定义灵活性不够,而且无法做到将外部的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.javaeye.com/topic/58084 。这里就不重复了。感谢 dengyin2000 的技术分享。官方网站是: http://gwt-widget.sourceforge.net/?q=node/39
部署GWT到Tomcat中
在我研究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会变得更出色)。
看了一些Javaeye中其他关于GWT的文章。感到很多人是因为GWT有太多有别于一般意义上的java语言的特性才对GWT产生了一些误解。抱歉,我这里不是在针对谁,毕竟我相信除了Google之外很少会有公司运用这个框架来开发项目。很多技术如果不是在实际项目中运用,仅凭自学是很难深入了解的。当然我并不是说GWT有多好,他也有局限性。坦率说我更喜欢wicket,个人觉得他融入了部分的GWT的客户端开发创意,而且很好的弥补了GWT中的一些不足之处。我喜欢这些有创意的开发理念,不断涌现的新创意会让Java这一技术更有意思。
作者:maqujun