GWT 中文文档, gwt.xml模块配置文件

GWT 中XML模块配置文件文档，中文版。 官方原文地址：http://code.google.com/intl/zh-CN/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=DevGuideModuleXml   如何定义个XML模块文件   模块是被定义于名为 gwt.xml.ModulName 的文件中。这个文件应改被放在你的工程的根目录。如果你的工程使用的GWT标准工程文件夹的结构，那么你的配置文件应该向下面那样简单。 <module>     <inherits name="com.google.gwt.user.User" />     <entry-point class="com.example.cal.client.CalendarApp" /> </module> 加载模块 模块配置的XML文件应该在JAVA的类加载路径里面。模块总是通过他们的逻辑名被引用。模 块的逻辑名是这样的：包名1.包名2.模块名。逻辑名并不用反映实际的文件系统路径和文件扩展名。如下，假如一个模块的XML文件：   ~/src/com/example/cal/Calendar.gwt.xml   那么对应的逻辑名可以是： com.example.cal.Calendar   重命名模块 模块配置文件的<module>元素有一个可选的属性 rename-to 。这个属性可以让JAVA -> JavaScript的编译器把对应模组按照重命名之后的名字来处理。重命名一个模块可以带来如下好处： 可以使用一个不反应实际包结构的短名 to create a "working module" to speed up development time by restricting the number of permutations （这个不知道该怎么译， 所以把原文放在这里。permutations 是排列组合的意思。） com.foo.WorkingModule.gwt.xml: <module rename-to="com.foo.MyModule"> <inherits name="com.foo.MyModule" /> <set-property name="user.agent" value="ie6" /> <set-property name="locale" value="default" /> </module> 对应如上的配置文件，当WorkingModule.gwt.xml被编译的时候，默认情况下将仅仅产生一个用于ie6的版本。这种方式可以帮助你提高开发时的编译速度。这时编译器的输出将是以重名后的包名产生的。 但是，在主机（Host）模式下，需要使用实际的XML文件名对应的模块名，即物理名。总之 主机模式下，GWT（谷歌网站工具）只会按照物理名去查找对应的模块。 使用多个模块 大多数情况下，你可能会打算创建一个可以在其他GWT工程中重用的模块。创建这类模块的时候并不意味着该模块必须要定义一个入口(entryPoint)。实际上， GALGWT（Google API Library for Google Web Toolkit ）中Gears对GWT的绑定中就有这种情况。你可以在jar包中的gwt-google-apis/com/google/gwt/gears/ Gears.gwt.xml 中看到，那里并没有定义入口。所以任何想要在GWT工程中使用Gears for GWT的模块都需要在其模块配置文件中继承Gears.gwt.xml module。例如： 一个名为 Foo 的模块项使用GALGWT, 则其模块配置文件中应该有一个<inherits> 元素。 <module> ...     <inherits name="com.google.gwt.gears.Gears" /> 在同一个超文本文件中加载多个模块 如果你的应用程序需要多个GWT模块， 那么你有两种方式加载它们。 1. 分别编译各个模块，然后应用程序的主页面中单独的在不同的<script>中去指定每个模块。 2.创建一个顶层的模块的XML配置文件，在其中包含所有你打算包含的模块。然后编译顶层模块， 进而只产生单个的js 输出结果。 第一种方法单独编译每个模块的方法似乎看起来更像是一种编译模块的方法。但是不幸的是， 在GWT中，这回引起应用程序开始的时候需要加载多个模块， 而多个模块这件会有大量的冗余 数据， 例如相同GWT库的文件，甚至还有可能遇到冲突。基于这些原因， 推荐使用第二种方式。   重载一个实现 <super-source>标签告诉编译器将一个目录作为源码的根目录。当你想在一个GWT工程中重用一个java的 api，而原先的源码路径又没法编译这个类的时候这个标签就有用武之地了(这句没有译出原话的意思来， 看后面的意思，等我都搞懂了再回来改)。这个功能多的时候用来模拟一个尚未被GWT实现的JRE的功能。 请看下面这个例子， 假设你打算实现JRE 下面java.util 下面的UUID 类， 你的工程的模块是： com/example/myproject/MyProject.gwt.xml. 那么你可以把UUID 类放到 com/example/myproject/jre/java/util/UUID.java. 然后在MyProject.gwt.xml 中加入<super-source path="jre" /> 这就告诉编译器将com/example/myproject/jre 加到源码路径下面，但是去掉，并且包括jre，之前的部分。 这样做的实际效果是， com/google/myproject/gwt/jre/java/util/UUID.java 将会被视作java/util/UUID.java 。 看到了吧， 这样实际上你为GWT的jre增加了一个类的实现。 基于GWT的工程内在的使用了这种技术来实现对JRE的模拟。必须指出是， 以这种对JRE类进行的重载实际上并不能被用于主机（host）模式。主机模式中， 本地的jre总是替代了 源码编译而来的类。 <super－source> 标签支持基于模式的过滤，这个特性使得你可以在更细的粒度上控制编译是那个资源被复制 到输出目录。 XML配置文件参考 这一节列出了模块配置文件中最常用的元素。 <inherits name="logical-module-name" /> :          从指定的模块继承所有的设置。这样做时间上是将所有的设置都复制的当前的这个文件。可以继承的模块数量不限。 <entry-point class="classname" /> :         定义一个入口类。可以定义任意数量的入口，当然被继承过来的入口同样有效。同一个有效域内的所有的入口都被编译到同一个代码库。并且，被按照出现在配置文件中的顺序依次的被各自的onModuleLoad()方法加载。 <source path="path" /> :           每个<source>标签都通过合并其所指定的路径到模块配置XML文件所指定的包中去的方法， 加入了一个包到编译器的源码路径内。所有出现在包中的java文件或者其子包都会被编译。同样，基于模式匹配的过滤也是支持的，以便于为你提供对编译输出，主要是对那些资源将被复制编译输出目录，提供细粒度的控制。如果整个模块配置文件都没有<source>标签被定义，那么client包将被隐式的加入到源码路径中去，这个动作等同于<source path = "client">.这个默认设置可以帮助大家使用google推荐的标准工程文件夹的组织方式。 <public path = "path" />            这个标签用于将一个包加入到public path 路径下面。所有出现于public path路径下面的资源将被所有的客户端代码访问。和source一样， <public> 也有一个默认的指向，模块根目录，就是模块配置文件所在的目录，下的public 文件夹。 <servlet path="url-path" class="classname" /> :           为了便于RPC测试，这个标签定义了一个servlet并将之绑定到一个URL，但是请注意，和在web.xml中定义不同， 1。此处要求URL的末尾必须是一个目录而不是”/”。在客户端代码中， 你可以指定一个调用位置，用ServiceDefTarget.setServiceEntryPoint(String).这里对加载的servlet的数量没有限制。2。这个地方的定义只对GWT的内置服务器的服务器端的调试起作用。 <script src ="js-url" /> :            在中用模块的主页中引入js文件或者文件夹，这个效果等同于你在HTML 页面中使用 script 。 <stylesheet src="css-url" /> :           在中用模块的主页中引入css文件或者文件夹，这个效果等同于你在HTML 页面中使用 script 。 <extend-property name="client-property-name" values="comma-separated-values" /> :           这个使用来定义本地化参数的，也可以用来定义其他的一些属性