This chapter is from the book
This chapter is from the book
This chapter is from the book
Organizing Your Application Structure
When you generate an application using GWT's applicationCreator script, the script creates files and directories that follow a recommended structure. Each application that you create shares your Projects directory. Figure 4-31 shows how the directory looks for the HelloWorld generated application. Figure 4-32 shows the directory result after running the applicationCreator again and adding the new application, HelloWorld2, to the same Eclipse project used for HelloWorld. Notice that new scripts were created for the HelloWorld2 application. The applicationCreator script creates the application source files in the src directory, and shares this directory with the first HelloWorld application, as shown in Figure 4-33.
)
Figure 4-31 Directory structure for the HelloWorld application
)
Figure 4-32 Directory structure after adding a new application
)
Figure 4-33 Two applications sharing the same source directory
The source code is organized in standard Java package structure. Since we created the application as com.gwt.examples.HelloWorld2, the script generates the source files in the src/com/gwt/ examples directory. This directory structure technique is a nice way of organizing Java modules and applications. It allows you to add packages and give them a unique location in the source tree, avoiding overwriting other classes that may be in a different package but have the same name. It also gives you a unique way to refer to a class from Java code.
Each generated GWT application has a module file and other source files in the client subdirectory and public subdirectory. Figure 4-33 shows the module file for HelloWorld2, HelloWorld2.gwt.xml. This file specifies the application's configuration options for the GWT compiler. The generated module file looks like this:
<module> <!-- Inherit the core Web Toolkit stuff. --> <inherits name='com.google.gwt.user.User'/> <!-- Specify the app entry point class. --> <entry-point class='com.gwtapps.examples.client.HelloWorld2'/> </module>
This is the minimum specification that the application needs to run. The GWT compiler needs to know the class that acts as the entry point to the application, specified with the entry-point tag, and it needs to use the com.google.gwt.user.User module for its user interface. When you need to use other modules in your application you specify their location here. The module file has many more configuration options, all of which are outlined on the GWT web site at http://code.google.com/webtoolkit.
Now let's look inside the public folder shown in Figure 4-34. For each generated application, the script creates a new HTML host file in the public directory. The GWT compiler considers files placed in the public directory to be part of the distribution. In other words, when you compile your application, GWT will copy all of the files in this directory to the www output directory. For example, we could move the CSS from inside the HTML host file to a separate CSS file and place it in this directory. Other common files you might place in this directory are images that are used in the application's user interface.
)
Figure 4-34 The public folder holding the static application files
The generated Java source file for the applications is found in the client directory, as shown in Figure 4-35. When the GWT compiler compiles the Java source to JavaScript, it compiles the Java files in this directory. Any files outside of this directory will not be compiled to JavaScript, and if you use them you will get an exception when compiling or running in hosted mode. However, using the inherits tag in your module file tells the GWT compiler to use another module.
)
Figure 4-35 The client directory holding the files that will be compiled to JavaScript
The GWT compile automatically includes subdirectories and packages in the client directory without inheriting a module. This is useful for organizing subcategories of code within your application. For example, many of the sample applications in this book use a model-view-controller (MVC) architecture and keep the model and view in subpackages. Figure 4-36 shows this type of organization for Chapter 7's Multi-Search sample application. You can use this to organize your client-side code into categories other than model and view.
)
Figure 4-36 MVC organization inside the client directory
There may be situations where you'll have application code that shouldn't be compiled to JavaScript and shouldn't be in the client directory; for example, when writing server-side code in Java, perhaps using a GWT RPC servlet. The common place to put this server-side code is in a server directory. For example, the Instant Messenger application in Chapter 9 places the servlet class in the server subdirectory, as shown in Figure 4-37. Since this is outside of the client directory, the GWT compile ignores the code when compiling the client. Typically the GWT compiler will not be able to compile server-side code since it usually uses packages that aren't emulated by GWT and would not be useful in a browser.
)
Figure 4-37 Server-side code is placed outside the client directory
The reverse is possible, however. The server classes can use classes in the client directory as long as they don't rely on browser features. The Instant Messenger application does this to share the Java classes that are used to transmit data over RPC between the client and the server.
Finally, when you're ready to deploy your application, you run the generated compile script. GWT copies all of the files used for distribution, including the generated JavaScript files and all of the files in the public directory, to the applications directory inside the www directory. The compiler names the application's directory with the full module name, as shown in Figure 4-38.
)
Figure 4-38 The GWT writes the compiled and static files to the www directory