Creating Ajax Web Applications Using the Google Web Toolkit (GWT) and Java
Java Programming Notes # 2550
- Preface
- General background information
- Preview
- Discussion and sample code
- Run the programs
- Summary
- What's next?
- Copyright
- Download
- Resources
- About the author
Preface
General
Development of Ajax web applications
Historically, the development of Ajax web applications has been a complex process. This is due mainly to the requirement to learn and use a variety of technologies, possibly including HTML, JavaScript, XML, ASP.NET, Java servlets, various scripting languages, etc.
Recently several products have emerged that make it possible to develop Ajax web applications using the Java development environment. Some use exclusively Java, while others use mainly Java.
The Google Web Toolkit (GWT)
One development environment that allows you to use mainly Java for the development of web applications is the Google Web Toolkit (GWT) (see Resources and Download).
Most of the client-side code for a GWT Ajax application can be written in Java. Apparently there is no requirement to write JavaScript code. However, it is necessary to:
- Create an HTML host page for the application.
- Create your own CSS style sheets.
- Compile your Java code using a special GWT Java-to-JavaScript compiler.
- Use a special scaled down version of the Java API, which only supports two packages from the standard J2SE API.
Not all standard Java packages are supported
The GWT only supports the following packages from the standard J2SE API:
- java.lang
- java.util
The GWT doesn't even fully support those two packages. For example, although
the Vector class is supported by the GWT, only two overloaded constructors for
that class are supported, whereas the Vector class in Sun's J2SE has four
overloaded constructors.
Not based on the latest version of Java
In addition, the GWT version 1.1.10 is apparently based on version 1.4.2 of Sun's J2SE. Therefore, many of the features that were added in J2SE 5.0 (such as generics) are not supported by the GWT.
You need to be careful
Therefore, you need to be careful when writing your Java application to make certain that you are using only those Java features that are supported by the GWT. (See the link to the GWT JRE Emulation Library in Resources for more information on this topic.)
First in a series
This is the first lesson in a series of lessons designed to help you learn how to use the GWT to create rich Ajax web applications.
Purpose of the tutorial
The purpose of this tutorial lesson is to help you get your computer set up to create Ajax web applications using the GWT. Future lessons will concentrate on the Java programming techniques required to create more meaningful Ajax web applications.
By the time you finish this tutorial, you should have your computer set up to create Ajax web applications, and you should have created and tested two basic applications.
Prerequisites
Knowledge of event-driven programming using the Java programming language as embodied in Sun's J2SE 5.0 (see DickBaldwin.com in Resources) is a prerequisite to understanding the material in this lesson.
Knowledge of how to deploy a web application in a Java servlet container (see "Deployment of Web Applications in Jakarta Apache Tomcat 5" in Resources) is a prerequisite for being able to replicate the results produced in this lesson.
System requirements
You will need to download and install the GWT framework (see Download).
You will need access to a servlet container for testing your web applications. One of the easiest ways to satisfy this requirement is to install a servlet container as a localhost server (see Download and also see "Getting Started with Jakarta Tomcat, Servlets, and JSP" in Resources).
Viewing tip
I recommend that you open another copy of this document in a separate browser window and use the following links to easily find and view the figures and listings while you are reading about them. You may also find it useful to open a third browser window at the Resources section near the end of the document. That will make it easy for you to open those resources when they are mentioned in the text.
Figures
- Figure 1. Three most useful items in the GWT framework.
- Figure 2. The initial GWT development tree.
- Figure 3. Screen output for the basic GWT web application.
- Figure 4. Screen output after the button has been clicked.
- Figure 5. Development tree after running GwtApp001-shell.cmd.
- Figure 6. Expanded development tree showing compiler output.
- Figure 7. The compiled application opened locally in a Firefox browser.
- Figure 8. Development tree after creation of second web application.
- Figure 9. Hosted mode screen output for second web application.
- Figure 10. Development tree after compiling second application.
- Figure 11. Tomcat server containing the files for two GWT applications.
Listings
- Listing 1. Java source code for the basic GWT web application.
- Listing 2. Source code for program used to produce tree displays.
Supplementary material
I recommend that you also study the other lessons in my extensive collection of online Java tutorials. You will find a consolidated index at www.DickBaldwin.com.
General background information
A few months ago, I decided that it was time for me to learn what Ajax technology is all about. I had a general idea of the technology based on some articles that I had read, and I had found several applications such as Google Maps and Google Suggest to be very impressive. Realistically, however, I didn't have any idea how to implement an Ajax application.
So, I started searching around and quickly discovered that several products have recently emerged that make it possible to develop web applications using the Java development environment. Some use exclusively Java, while others use mainly Java. Two products that use exclusively Java are products named ThinWire and Echo2. (See the link to "Developing Ajax Web Applications using ThinWire and Java" and the link to Echo2 in Resources.)
My strong suite is Java
Since my strong suite is Java and not JavaScript, I have been pleased to learn that there are at least three emerging technologies that make it possible to develop Ajax applications using Java without much, if any requirement to write JavaScript, HTML, XML, CSS, etc.
Exclusively Java
The folks at ThinWire (see Resources) describe their product as follows:
- Familiar event-driven GUI programming model
- Develop exclusively in server-side language only
- Never use HTML, CSS, or JavaScript again
- Program exclusively in Java
- All Major Browsers Supported
- Deploy on any Java Servlet Container (including Apache Tomcat)
- Also Runs on Nokia 770 Internet Tablet
The folks at NextApp (see Resources) have this to say about their Echo2 product:
"Echo2 is ... a platform for developing web-based applications that approach the capabilities of rich clients. The 2.0 version ... providing dramatic performance, capability, and user-experience enhancements made possible by its new Ajax-based rendering engine.
Echo2 removes the developer from having to think in terms of "page-based" applications and enables him/her to develop applications using the conventional object-oriented and event-driven paradigm for user interface development. Knowledge of HTML, HTTP, and JavaScript is not required. Applications may be hosted using any Java servlet container."
Similar to event-driven desktop applications
Thus, developing web applications using ThinWire and Echo2 is very similar to developing standalone event-driven Java desktop applications. While both products provide their own proprietary API for the construction, layout, and management of the user interface, for the most part, the remainder of the application is true to Sun's J2SE 5.0.
In both cases, you substitute the proprietary user interface API for the standard Java user interface API and then write the Java program as though it is intended to be an event-driven desktop application. Then you compile the application using Sun's standard javac compiler, at which time it is converted into a servlet-based web application.
Mainly Java - the GWT
As I mentioned in an earlier lesson entitled "Deployment of Web Applications in Jakarta Apache Tomcat 5" (see Resources) the GWT folks at Google have this to say about their framework:
"Google Web Toolkit (GWT) is a Java development framework that lets you escape the matrix of technologies that make writing AJAX applications so difficult and error prone. With GWT, you can develop and debug AJAX applications in the Java language using the Java development tools of your choice. When you deploy your application to production, the GWT compiler translates your Java application to browser-compliant JavaScript and HTML."
Not nearly as close to standard Java...
The GWT is not nearly as close to standard Java as are ThinWire and Echo2. For example, the GWT requires that you use a proprietary Google API for the entire development process. Only two packages from Sun's version 1.4.2 API are supported, and neither of those APIs is fully supported by GWT version 1.1.10. For example, some constructors, and possibly some methods as well from those two packages in Java 1.4.2 are not supported by the GWT version 1.1.10.
None of the features that Sun added in J2SE 5.0 are officially supported by GWT version 1.1.10. Therefore, if you are accustomed to taking advantage of those features in your Java applications, you must be careful to avoid them when writing Java code for the GWT. In addition, you must be careful not to write any Java version 1.4.2 code that is not supported by the GWT.
Must use Google's proprietary compiler
Once you have the Java application written, you must compile it using a proprietary Google Java-to-JavaScript compiler in order to turn it into a web application.
Major differences in deployment strategy
There are also major differences in the way that GWT applications are deployed and executed relative to ThinWire and Echo2 web applications. Some of these differences may be advantages, and some may be disadvantages.
Servlet-based web applications
ThinWire and Echo2 both produce web applications that are based on Java servlets. The user causes a servlet to be executed on the server to execute the application. The servlet then dynamically generates the necessary client code (which probably includes a lot of JavaScript) and downloads it to the client machine where it is executed. The downside of this approach is that web applications created using ThinWire and Echo2 can only be deployed on servers that support servlets.
JavaScript-based web applications
A GWT web application compiles directly into JavaScript, producing a web application that does not require a servlet-compatible server for deployment. The upside of this is that it should be possible to deploy a GWT web application on just about any web server without a requirement for Java servlet compatibility.
(See Resources for two online articles that compare the GWT with ThinWire and Echo2, keeping in mind that those comparisons were written by people who have a vested interest in ThinWire and Echo2.)
Preview
Eight critical steps
The development and deployment of Ajax web applications using the GWT consists of the following steps:
- Download and install the GWT framework.
- Prepare your computer for developing Ajax web applications using the GWT.
- Use the GWT applicationCreator script to create the Java source code and other files required for a basic GWT web application.
- Use your Java editor to upgrade the basic web application to suit your requirements. Frequently test the application in GWT hosted mode as the Java coding effort progresses.
- Compile the finished Java web application into a JavaScript web application using the proprietary GWT Java-to-JavaScript compiler.
- Test the compiled web application locally simply by loading the host page into the browsers of interest.
- Deploy the compiled web application onto a web server and test it by downloading it from the web server and executing it in the browsers of interest.
- Repeat steps 3 through 7 to create, test, and deploy additional GWT web applications.
Not technically challenging, but very tedious
If you already know how to program using the Java programming language, none of the steps described above are technically challenging. However, they can be very tedious and there are many opportunities for error.
I will teach you my procedure
In this lesson, I will walk you through the procedure that I followed to accomplish the steps listed above on a machine configured as follows:
- Windows XP.
- A jakarta-tomcat-5.0.27 server running as a localhost server.
- A Firefox browser.
- The GWT version 1.1.10.
The primary emphasis of the lesson
The primary emphasis of this lesson will be on all of the steps in the above list except Step 4. That step has to do with upgrading the Java source code for the basic web application produced by the applicationCreator script. I will barely touch on that step in this lesson. I will concentrate on teaching you how to create and deploy two slightly different but very basic Ajax web applications.
In other words, the purpose of this lesson is to help you get set up to produce more meaningful Ajax web applications using the GWT. Future lessons will concentrate on the Java programming techniques required to produce those more meaningful Ajax web applications.
Discussion and sample code
Download and install the GWT framework
The first step is to download and install the GWT framework. As of the date of this writing, the framework can be downloaded from http://code.google.com/webtoolkit/download.html. The framework consists of a single file named gwt-windows-1.1.10.zip.
No Windows installation required
There is no requirement to perform a Windows installation for the framework. All that is required is to extract the contents of the zip file into a known location on your disk. I extracted the contents of the zip file into a directory named C:progfileGwtV1.1.10-noUninstallReq.
(You may choose to extract the files into a different directory. I am providing you with the location on my computer because the path will be important later when I get to the discussion of the script named applicationCreator.)
Some interesting side issues
If you poke around in the directory tree produced by extracting the framework from the zip file, you may conclude that (other than the Java class library) the three most useful items in that directory tree are the items listed in Figure 1.
Figure 1. Three most useful items in the GWT framework.
C:...gwt-windows-1.1.10applicationCreator.cmd C:...gwt-windows-1.1.10docjavadocindex.html C:...gwt-windows-1.1.10samples |
The applicationCreator script
The first item in the list in Figure 1 is the name of an executable file that, as you will see later, is executed to create a basic GWT web application for each new web application that you write.
The API documentation
The second item in the list in Figure 1 is the name of a file that forms the root of a set of javadocs that describe the GWT framework API. If you open this file in your browser, you will see that it displays standard Java documentation for the API.
(Unfortunately, there appear to be some important images missing from this documentation. Those images can be viewed in the online version of the API documentation mentioned in the next paragraph.)
In addition to the API documentation contained in the downloadable zip file, a great deal more documentation on the GWT can be found at the Google Web Toolkit link in Resources.
Sample applications
The third item in the list in Figure 1 is the name of a directory that contains the Java source code and the compiled versions of seven different GWT web applications of varying complexity. These sample applications may be useful to you in your efforts to learn how to program using the proprietary GWT Java API.
Prepare your computer for developing GWT applications
There are many different ways to prepare your computer for the development of web applications in order to accomplish Step 2. My preference is to create a development directory tree that mirrors the deployment directory tree on the server. Then when an application has been created in the development tree all that is necessary to deploy it to the server is to copy portions of the development tree to the deployment tree. I explained this approach in the earlier lessons entitled "Deployment of Web Applications in Jakarta Apache Tomcat 5" and "Developing Ajax Web Applications using ThinWire and Java" (see Resources).
A GWT development directory
To start this process, I created the following GWT development directory as the root of my GWT development tree:
C:BaldwinAA-SchoolJavaProgwebappsGwtApps
The rest of the GWT portion of the development tree will be filled in below this directory later.
Create the Java source code and other files required for a basic GWT web application
To accomplish Step 3, I opened a command prompt in the GwtApps directory and executed the following command in that directory to create a basic GWT application:
C:progfileGwtV1.1.10-noUninstallReqgwt-windows-1.1.10applicationCreator
GwtApp.client.GwtApp001
(Note the use of the path to the GWT script named applicationCreator. Also note the command line parameter shown in boldface and compare it with the actual tree that was created as shown in Figure 2 below.)
The GWT application directory tree
The execution of the GWT script named applicationCreator created a directory tree underneath the GwtApps directory containing the files and folders shown in Figure 2.
Figure 2. The initial GWT development tree.
Dir: GwtApps .GwtApp001-compile.cmd .GwtApp001-shell.cmd .Dir: src ..Dir: GwtApp ...Dir: client ....GwtApp001.java ...GwtApp001.gwt.xml ...Dir: public ....GwtApp001.html |
The Java source code
The Java source code that was automatically generated for the basic GWT web application is contained in the file named GwtApp001.java shown in Figure 2. That source code is shown in Listing 1.
Listing 1. Java source code for the basic GWT web application.
package GwtApp.client;
import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.ui.Button;
import com.google.gwt.user.client.ui.ClickListener;
import com.google.gwt.user.client.ui.Label;
import com.google.gwt.user.client.ui.RootPanel;
import com.google.gwt.user.client.ui.Widget;
/**
* Entry point classes define
* <code>onModuleLoad()</code>.
*/
public class GwtApp001 implements EntryPoint {
/**
* This is the entry point method.
*/
public void onModuleLoad() {
final Button button = new Button("Click me");
final Label label = new Label();
button.addClickListener(new ClickListener() {
public void onClick(Widget sender) {
if (label.getText().equals(""))
label.setText("Hello World!");
else
label.setText("");
}
});
// Assume that the host HTML has elements defined
// whose IDs are "slot1", "slot2". In a real
// app, you probably would not want to hard-code
// IDs. Instead, you could, for example, search
// for all elements with a particular CSS
// class and replace them with widgets.
//
RootPanel.get("slot1").add(button);
RootPanel.get("slot2").add(label);
}
}
|
The first boldface item in Listing 1 shows the extent to which the Java source code was customized to match the name of the application specified in the execution of the applicationCreator script earlier.
Don't intend to teach much about Java source code in this lesson
Recall that it is not the purpose of this lesson to teach you how to produce meaningful Ajax web applications using the GWT. Rather, that will be covered in future lessons. However, later on in this lesson, I will show you how to create a different GWT web application by modifying the text on the face of the button shown in boldface in Listing 1 (and also shown in the image in Figure 3). I am showing you the Java source code that is automatically generated by the GWT applicationCreator script so you will know what to expect later.
What about the other generated files?
Now, getting back to the directory tree shown in Figure 2, the exact purpose of the file named GwtApp001.gwt.xml isn't clear to me, but it is generated automatically and is required. You should just leave it alone during the remainder of the development of the web application.
The host page
The file named GwtApp001.html shown in Figure 2 is used later in Step 6 (compilation of the web application) to produce another file having the same name that is referred to in the GWT documentation as the host page. (See the boldface material in Figure 6.) A copy of the file shown in Figure 6 is downloaded from the web server by the user in order to execute the web application later. You will probably modify the version of the file shown in Figure 2 during the development of the web application. I will explain that in the next lesson.
Two script files
You will learn the purpose of the files named GwtApp001-compile.cmd and GwtApp001-shell.cmd later. These are script files that you will execute later. You must not modify these two files.
Upgrade the basic web application to suit your requirements
That covers the first three steps. At this point, there is nothing that we need to do to upgrade the basic web application that was automatically generated by executing the applicationCreator script. We will simply leave the Java source code for the application unmodified, skipping Step 4, and continue on to Step 5. Before discussing Step 5, however, I need to mention a little about testing the web application in hosted mode. (I will have a great deal more to say about testing in hosted mode in the next lesson.)
Frequently test the application in GWT hosted mode as the Java coding effort progresses
As you write the Java source code for your GWT web application, you should test it frequently in GWT hosted mode. This is accomplished by executing a command similar to the following at the command prompt to run the GWT script named GwtApp001-shell.cmd.
C:BaldwinAA-SchoolJavaProgwebappsGwtAppsGwtApp001-shell.cmd
(Note that the script file mentioned above is shown in Figure 2, and contains the name of the web application in the file name. A new script file is automatically generated for each new web application that you create using the GWT.)
The screen output
Running this script in this case produced the screen output shown in Figure 3.
Figure 3. Screen output for the basic GWT web application.
|
|
This is the output produced by converting the Java source code shown in Listing 1 into a GWT web application. Note, however, that this is not a compiled web application. Rather this is a preliminary view of the behavior of the application running in a special Google GWT browser. As mentioned earlier, Google refers to this as the hosted mode.
Click the button
The button shown in Figure 3 will be active when you run the script. Clicking that button should cause the web application to produce the screen output shown in Figure 4. (Note the text to the right of the button.)
Figure 4. Screen output after the button has been clicked.
|
|
If you compare this behavior with the Java code shown in Listing 1, you should see that the application is behaving as expected based on that Java code.
Where did the extra text dome from?
By now, you may be wondering where the extra text in Figure 3 and Figure 4 came from. It clearly wasn't generated by the Java code shown in Listing 1. The answer is that this text was produced by the file named GwtApp001.html shown in Figure 2. I will have much more to say about this in the next lesson.
(If you were to open the file named GwtApp001.html in your browser, you would see the extra text there.)
The development directory tree has expanded
Executing the GWT script named GwtApp001-shell.cmd not only caused the application output to be displayed on the screen in hosted mode, it also expanded the development directory tree to that shown in Figure 5.
Figure 5. Development tree after running GwtApp001-shell.cmd.
Dir: GwtApps .GwtApp001-compile.cmd .GwtApp001-shell.cmd .Dir: src ..Dir: GwtApp ...Dir: client ....GwtApp001.java ...GwtApp001.gwt.xml ...Dir: public ....GwtApp001.html .Dir: tomcat ..Dir: conf ...Dir: gwt ....Dir: localhost ...web.xml ..Dir: webapps ...Dir: ROOT ....Dir: WEB-INF .....web.xml ..Dir: work ...Dir: gwt ....Dir: localhost .....Dir: _ ......tldCache.ser |
The primary difference
The primary difference between the tree shown in Figure 5 and the tree shown earlier in Figure 2 is the addition of a complete new sub-tree rooted in the directory named tomcat in Figure 5.
Apparently the first time that the script named GwtApp001-shell.cmd is executed, it installs a local Tomcat web server that is used to execute the application in hosted mode.
Compile the finished Java web application
The next step (Step 5) is to use the proprietary GWT Java-to-JavaScript compiler to compile the finished Java web application into a JavaScript-based web application. There are at least two ways to accomplish this. One way is to click the button labeled Compile/Browse at the top of Figure 3. The other way is to execute the following command at the command prompt:
C:BaldwinAA-SchoolJavaProgwebappsGwtAppsGwtApp001-compile.cmd
This causes the GWT script named GwtApp001-compile.cmd to be executed. This script compiles the application creating the folders and files shown in boldface in the expanded development directory tree shown in Figure 6.
(Clicking the button labeled Compile/Browse at the top of Figure 3 not only attempts to compile the application, it also attempts to execute it locally in your default browser.
Note that some of the long and cryptic file names in Figure 6 may or may not be different on your computer if you create this web application. I'm not certain about that.)
Figure 6. Expanded development tree showing compiler output.
Dir: GwtApps .GwtApp001-compile.cmd .GwtApp001-shell.cmd .Dir: src ..Dir: GwtApp ...Dir: client ....GwtApp001.java ...GwtApp001.gwt.xml ...Dir: public ....GwtApp001.html .Dir: tomcat ..Dir: conf ...Dir: gwt ....Dir: localhost ...web.xml ..Dir: webapps ...Dir: ROOT ....Dir: WEB-INF .....web.xml ..Dir: work ...Dir: gwt ....Dir: localhost .....Dir: _ ......SESSIONS.ser ......tldCache.ser .Dir: www ..Dir: GwtApp.GwtApp001 ...2DAE4A7B24DAE434541E6F0DAB7F722A.cache.html ...2DAE4A7B24DAE434541E6F0DAB7F722A.cache.xml ...3FF6F7B1D8AF1B5F2326A742F504551C.cache.html ...3FF6F7B1D8AF1B5F2326A742F504551C.cache.xml ...6EEE47E0C45E090ED654C108CE71BE75.cache.html ...6EEE47E0C45E090ED654C108CE71BE75.cache.xml ...D707D2EEF881B4713E46525326B66438.cache.html ...D707D2EEF881B4713E46525326B66438.cache.xml ...gwt.js ...GwtApp.GwtApp001.nocache.html ...GwtApp001.html ...history.html ...tree_closed.gif ...tree_open.gif ...tree_white.gif |
The directory named GwtApp.GwtApp001 and its contents constitute the JavaScript/HTML version of the web application.
Test the compiled web application locally
The next step is described in the above list as Step 6. This web application can be tested locally by opening the file named GwtApp001.html (shown in boldface in Figure 6 and known as the host page) in a browser.
(Note that there are two files named GwtApp001.html in Figure 6. The file of interest at this point, (the host page) is the one shown in boldface in the directory tree rooted in the directory named www. The other file having the same name is contained in the directory named public.
As mentioned above, opening the host page file locally in your browser happens automatically if you click the button labeled Compile/Browse at the top of Figure 3.)
The screen output
Opening the host page file in your browser should result in the screen output shown in Figure 7 (where the host page file named GwtApp001.html was opened in a Firefox browser).
(Note that opening the file named GwtApp001.html shown in the non-boldface public directory in Figure 6 will not result in an operational web application.)
Figure 7. The compiled application opened locally in a Firefox browser.
|
|
The behavior produced by clicking the button in Figure 7 should match that shown in the output for the hosted mode earlier in Figure 2 and Figure 3.
Deploy and test the compiled web application
The next step, Step 7, is to deploy the compiled web application onto a web server and to test it by downloading it from the web server and executing it in the browsers of interest.
To deploy the application to my localhost server, I copied all of the folders
and files in the development directory named www into the jakarta tomcat server
directory named C:jakarta-tomcat-5.0.27webappsGwtApps.
Then I added the following directory and file to the localhost Tomcat server.
C:jakarta-tomcat-5.0.27webappsGwtAppsWEB-INFweb.xml
A named web application
Note that the WEB-INF directory and the web.xml file were required
by my localhost server in order for me to deploy the application as a
named web application even though the file named web.xml is essentially empty.
However, this is not the only way to deploy a GWT web application, and I'm sure
there are other ways that don't require the presence of the web.xml file.
Running the web application
After deploying the web application, I was able to start the Tomcat server and to run the web application in my browser by entering the following URL into my browser window (note that this URL ends with the name of the host page):
http://localhost/GwtApps/GwtApp.GwtApp001/GwtApp001.html
The screen output and behavior was the same as that produced by opening the file named
GwtApp001.html directly in the Firefox browser as shown in Figure 7.
Create and deploy another GWT web application
That completes the seven steps required to:
- Download and install the GWT framework.
- Prepare your computer for the development of GWT web applications.
- Create, deploy and test a GWT web application.
Step 8, (which requires repeating steps 3 through 7) is used for the creation, testing, and deployment of additional GWT web applications. I will walk you through the procedure that I used to create, test, and deploy another simple GWT web application so that you can see the impact that this had on the development directory tree.
Create the basic web application
By
this time in my procedure, the window containing the command-line prompt had been closed so I
re-opened a command line prompt in the GwtApps directory of the development
tree. Then
I executed the following command in that directory to create another application
named GwtApp002:
C:progfileGwtV1.1.10-noUninstallReqgwt-windows-1.1.10applicationCreator
GwtApp.client.GwtApp002
(This corresponds to Step 3 in the list of eight critical steps presented earlier.)
Did not create a new development directory tree
Note that this did not create a new development directory tree. Rather, it expanded the existing development directory tree to that shown in Figure 8.
Figure 8. Development tree after creation of second web application.
Dir: GwtApps .GwtApp001-compile.cmd .GwtApp001-shell.cmd .GwtApp002-compile.cmd .GwtApp002-shell.cmd .Dir: src ..Dir: GwtApp ...Dir: client ....GwtApp001.java ....GwtApp002.java ...GwtApp001.gwt.xml ...GwtApp002.gwt.xml ...Dir: public ....GwtApp001.html ....GwtApp002.html .Dir: tomcat ...// Tree contents deleted for brevity //... ...tree_white.gif |
Several new files were created
As you can see, executing the applicationCreator script to create a new application added a number of new files to the development tree. I have highlighted those new files in boldface in Figure 8.
(Note that no new files were added to the tree in the area below the tomcat directory in Figure 8, so I deleted that portion of the tree from Figure 8 for brevity.)
A new Java source code file
One of the new files in Figure 8 is the Java source code file named
GwtApp002.java. The contents of this file were initially the
same as shown in Listing 1 except that each occurrence of GwtApp001
in the source code was replaced
by GwtApp002.
A new and different web application
To demonstrate that this is a new and different GWT web application, I opened that Java source code file in my Java editor and modified the text on the button to read GwtApp002 instead of Click me as shown in Listing 1 and Figure 3. (This corresponds to Step 4 in the list of eight critical steps presented earlier.)
Execute the script to test in hosted mode
Continuing with Step 4, another of the new files in the development directory tree shown in Figure 8
is the script file named GwtApp002-shell.cmd. (Note that
the script file contains the application name in the script's file name.) I executed that
script to test
the modified application in hosted mode. This produced the screen output
shown in Figure 9.
Figure 9. Hosted mode screen output for second web application.
|
|
Text on the button has changed
As you can see, the text on the button in Figure 9 matches the change to the Java source file that I described earlier. However, since changing the text on the button was the only change that I made, the behavior of the button in this application is the same as the previous application named GwtApp001.
Compile the web application into JavaScript
Another of the new files shown in Figure 8 is the script file named
GwtApp002-compile.cmd. I executed this script to compile the
application into a JavaScript web application. (This corresponds to
Step 5 in the earlier list of eight critical steps.)
This expanded the development directory tree to that shown in Figure 10.
(There were no changes to the development tree in the area above the directory named www, so I deleted that portion of the tree from Figure 10 for brevity.)
Figure 10. Development tree after compiling second application.
Dir: GwtApps
...// Tree contents deleted for brevity //...
.Dir: www
..Dir: GwtApp.GwtApp001
...2DAE4A7B24DAE434541E6F0DAB7F722A.cache.html
...2DAE4A7B24DAE434541E6F0DAB7F722A.cache.xml
...3FF6F7B1D8AF1B5F2326A742F504551C.cache.html
...3FF6F7B1D8AF1B5F2326A742F504551C.cache.xml
...6EEE47E0C45E090ED654C108CE71BE75.cache.html
...6EEE47E0C45E090ED654C108CE71BE75.cache.xml
...D707D2EEF881B4713E46525326B66438.cache.html
...D707D2EEF881B4713E46525326B66438.cache.xml
...gwt.js
...GwtApp.GwtApp001.nocache.html
...GwtApp001.html
...history.html
...tree_closed.gif
...tree_open.gif
...tree_white.gif
..Dir: GwtApp.GwtApp002
...675089A3F2F9763D53025CFC4B1361BA.cache.html
...675089A3F2F9763D53025CFC4B1361BA.cache.xml
...A585731848FCA1FF3F137A78EE82486C.cache.html
...A585731848FCA1FF3F137A78EE82486C.cache.xml
...B6D730DED1D0532D5837B14BA74ABD28.cache.html
...B6D730DED1D0532D5837B14BA74ABD28.cache.xml
...FA7B5B0A01ADC8314D693B3833776966.cache.html
...FA7B5B0A01ADC8314D693B3833776966.cache.xml
...gwt.js
...GwtApp.GwtApp002.nocache.html
...GwtApp001.html
...GwtApp002.html
...history.html
...tree_closed.gif
...tree_open.gif
...tree_white.gif
|
The added material is shown in boldface
The material that was added to the development tree by compiling the
second web application is shown in boldface in
Figure 10. In essence, a complete new sub-tree containing compiled JavaScript code,
HTML files, and XML files
was added to the development tree as a new sub-tree rooted in the directory
named GwtApp.GwtApp002.
(The file named SESSIONS.ser shown in boldface in Figure 6 was also modified during the development of the second web application. This seems to happen when you close the two special GWT host mode browsers. This leads me to believe that this is some sort of a history file associated with host mode testing. In any event, this file is not involved in the deployment of the compiled web application to the server.)
Some extra files in Figure 10
Note that for reasons I don't understand, in addition to the file
named GwtApp002.html, this sub-tree also contains a file named GwtApp001.html.
However, opening that file in my Firefox browser results in an output with a
missing button. In addition, deleting the file named GwtApp001.html from
the sub-tree doesn't
appear to have any detrimental impact on the ability to run the application by
opening GwtApp002.html directly in the browser or to deploy the application
named GwtApp002.html in
the localhost server.
Test the application in a local browser
Proceeding to Step 6, opening GwtApp002.html in my Firefox browser produced
essentially the same output that was produced earlier in hosted mode as shown in Figure
9.
Deploy the new application
The final test (Step 7) was to deploy the new application on my localhost tomcat
server. I copied the new development directory tree rooted in
GwtApp.GwtApp002 into the server directory named C:jakarta-tomcat-5.0.27webappsGwtApps
on my server.
By this time, my localhost Tomcat server was no longer running so I restarted it. I was then able to execute the new application by entering the following URL into the Firefox browser:
http://localhost/GwtApps/GwtApp.GwtApp002/GwtApp002.html
(Note once again that the last item in the URL is the name of the host page, GwtApp002.html.)
Screen output for the new application
The output was the same as that produced by opening the file named
GwtApp002.html directly in the Firefox browser and was essentially
the same as that produced by running the application in hosted mode as shown in
Figure 9.
My localhost server sub-tree
For the record, at this point in time my localhost server sub-tree rooted in the
directory named C:jakarta-tomcat-5.0.27webappsGwtApps contained the
directories and files shown in Figure 11.
Figure 11. Tomcat server containing the files for two GWT applications.
Dir: GwtApps .Dir: GwtApp.GwtApp001 ..2DAE4A7B24DAE434541E6F0DAB7F722A.cache.html ..2DAE4A7B24DAE434541E6F0DAB7F722A.cache.xml ..3FF6F7B1D8AF1B5F2326A742F504551C.cache.html ..3FF6F7B1D8AF1B5F2326A742F504551C.cache.xml ..6EEE47E0C45E090ED654C108CE71BE75.cache.html ..6EEE47E0C45E090ED654C108CE71BE75.cache.xml ..D707D2EEF881B4713E46525326B66438.cache.html ..D707D2EEF881B4713E46525326B66438.cache.xml ..gwt.js ..GwtApp.GwtApp001.nocache.html ..GwtApp001.html ..history.html ..tree_closed.gif ..tree_open.gif ..tree_white.gif .Dir: GwtApp.GwtApp002 ..675089A3F2F9763D53025CFC4B1361BA.cache.html ..675089A3F2F9763D53025CFC4B1361BA.cache.xml ..A585731848FCA1FF3F137A78EE82486C.cache.html ..A585731848FCA1FF3F137A78EE82486C.cache.xml ..B6D730DED1D0532D5837B14BA74ABD28.cache.html ..B6D730DED1D0532D5837B14BA74ABD28.cache.xml ..FA7B5B0A01ADC8314D693B3833776966.cache.html ..FA7B5B0A01ADC8314D693B3833776966.cache.xml ..gwt.js ..GwtApp.GwtApp002.nocache.html ..GwtApp002.html ..history.html ..tree_closed.gif ..tree_open.gif ..tree_white.gif .Dir: WEB-INF ..web.xml |
Figure 11 contains the directories and files for two different GWT Ajax applications. One application is highlighted using Italics in Figure 11. The other application is highlighted in boldface.
Creating the directory trees for display
In case you are interested, the various directory tree displays shown in this lesson were produced using a very crude recursive Java program that I threw together for that purpose. The source code for the program is provided in Listing 2.
Listing 2. Source code for program used to produce tree displays.
/*File Recur03.java Copyright 2006,R.G.Baldwin
Revised 10/15/06
Recursive program to display the tree structure
of the directories and files on the disk.
Tested using J2SE 5.0 under WinXP.
**********************************************************/
import java.io.*;
import java.util.*;
class Recur03{
public static void main(String[] args){
Recur03 thisObj = new Recur03();
thisObj.listDirTree(
"C:/Baldwin/AA-School/JavaProg/webapps/GwtApps",0);
thisObj.prevList = null;
thisObj.currentList = thisObj.root;
System.out.println();
thisObj.traverseTree();
}//main
//-----------------------------------------------------//
ArrayList root = new ArrayList();
ArrayList prevList;
ArrayList currentList;
Recur03(){//constructor
prevList = null;
currentList = root;
}//end constructor
//Method to list the contents of a directory
// and all its subdirectories. First parameter
// specifies the directory. Second parameter
// specifies the indentation level in the
// display.
public void listDirTree(String theDir,int indent){
//Get a File object that represents the
// directory.
File fileObj = new File(theDir);
//Make certain that the directory exists.
if(fileObj.exists()){
//Confirm that the File object represents
// a directory and not a file.
if(fileObj.isDirectory()){
//Get a list of the directory contents
// in an array object.
File[] dirContents = fileObj.listFiles();
//Display the name of the directory after
// performing indentation.
doIndent(indent);
String item = theDir.substring(theDir.lastIndexOf(
"\") + 1,theDir.length());
System.out.println("Dir: " + item);
currentList.add("Dir: " + item);
//Process the contents of the directory
// that were saved in the list of
// of contents.
for(int cnt = 0;cnt < dirContents.length;
cnt++){
if(dirContents[cnt].isDirectory()){
//Make a recursive call to process
// this directory before processing
// the remaining contents in the
// list of contents. Increase the
// indentation level in the recursive
// call.
prevList = currentList;
currentList.add(new ArrayList());
listDirTree(dirContents[cnt].getPath(),
indent + 1);
}else if(dirContents[cnt].isFile()){
item = dirContents[cnt].getPath().substring(
dirContents[cnt].getPath().lastIndexOf("\")
+ 1,dirContents[cnt].getPath().length());
doIndent(indent + 1);
System.out.println(item);
currentList.add(item);
}//end else
}//end for loop
currentList = prevList;
}else{
System.out.println(theDir + ": not a directory.");
}//end else
}else{
System.out.println("Directory " + theDir
+ " does not exist.");
}//end else
}//end listDirTree
//-----------------------------------------------------//
//Traverse the arrayList tree displaying the contents.
void traverseTree(){
int index = 0;
for(index = 0;index < currentList.size();index++){
Object item = currentList.get(index);
if(item instanceof ArrayList){
prevList = currentList;
currentList = (ArrayList)(prevList.get(index));
traverseTree();
}else{
if((item.toString()).substring(0,4).equals(
"Dir:")){
System.out.println(item);
}else{
System.out.println("File: " + item);
}//end else
}//end else
}//end for loop
currentList = prevList;
}//end traverseTree
//-----------------------------------------------------//
//This method positions the display cursor
// for indentation. Note that it inserts two
// spaces per indentation level.
public static void doIndent(int indent){
for(int cnt=0;cnt<indent;cnt++){
System.out.print(".");
}//end for loop
}//end doIndent
//-----------------------------------------------------//
}//end Recur03class
|
Note that this program in its current
form is not pretty but it works. Also, it does not provide for user input. Therefore, it is necessary to modify
the source code and recompile the program to create a tree for each different
path.
Run the programs
I encourage you to download and install the GWT framework and the Jakarta Tomcat server (see Download) and to use those products along with my Java source code to replicate what you have learned in this lesson.
Modify the source code in the Java files that are produced by the GWT applicationCreator script. Experiment with that code by compiling your modified web applications and observing the impact of your changes.
Experiment with the buttons at the top of the special GWT hosted mode browser shown in Figure 3.
Learn how to write web applications using this exciting new technology. Above all, enjoy the process. Programming can be fun.
Summary
The development and deployment of Ajax web applications using the GWT consists of the following eight steps:
- Download and install the GWT framework.
- Prepare your computer for developing Ajax web applications using the GWT.
- Use the GWT applicationCreator script to create the Java source code and other files required for a basic GWT web application.
- Use your Java editor to upgrade the basic web application to suit your requirements. Frequently test the application in GWT hosted mode as the Java coding effort progresses.
- Compile the finished Java web application into a JavaScript web application using the proprietary GWT Java-to-JavaScript compiler.
- Test the compiled web application locally in the browsers of interest.
- Deploy the compiled web application onto a web server and test it by downloading it from the web server and executing it in the browsers of interest.
- Repeat steps 3 through 6 to create, test, and deploy additional GWT web applications.
In this lesson, I walked you through the procedure that I followed to accomplish the steps listed above on a machine configured as follows:
- Windows XP
- A jakarta-tomcat-5.0.27 server running as a localhost server
- A Firefox browser
- The GWT version 1.1.10
The primary emphasis in this lesson included all of the steps in the above list other than Step 4 having to do with upgrading the Java source code for the basic web application produced by the applicationCreator script. I barely touched on that step in order to show you how to create and deploy two slightly different Ajax web applications.
In other words, the purpose of this lesson was to help you get set up to produce meaningful Ajax web applications using the GWT.
What's next?
Future lessons will concentrate on the Java programming techniques required to produce more meaningful Ajax web applications using the GWT framework. The next lesson in the series will deal with user interface layout issues in the web application.
Future lessons will deal with such issues as the available GWT user interface components, event-driven programming, and styling.
Copyright
Copyright 2006, Richard G. Baldwin. Reproduction in whole or in part in any form or medium without express written permission from Richard Baldwin is prohibited.
Download
Resources
- Google Web Toolkit
- The GWT JRE Emulation Library
- Developing Ajax Web Applications using ThinWire and Java
- Deployment of Web Applications in Jakarta Apache Tomcat 5
- Comparing the Google Web Toolkit to Echo2
- Seven Points to Consider: ThinWire Compared To The Google Widget Toolkit (June 2006)
- NextApp's Echo2 main page
- Google Web Toolkit: Ajax Apps from Java
- Visit DickBaldwin.com to view more than 500 programming tutorials written by this author.
- Getting Started with Jakarta Tomcat, Servlets, and JSP
About the author
Richard Baldwin is a college professor (at Austin Community College in Austin, TX) and private consultant whose primary focus is a combination of Java, C#, and XML. In addition to the many platform and/or language independent benefits of Java and C# applications, he believes that a combination of Java, C#, and XML will become the primary driving force in the delivery of structured information on the Web.Richard has participated in numerous consulting projects and he frequently provides onsite training at the high-tech companies located in and around Austin, Texas. He is the author of Baldwin's Programming Tutorials, which have gained a worldwide following among experienced and aspiring programmers. He has also published articles in JavaPro magazine.
In addition to his programming expertise, Richard has many years of practical experience in Digital Signal Processing (DSP). His first job after he earned his Bachelor's degree was doing DSP in the Seismic Research Department of Texas Instruments. (TI is still a world leader in DSP.) In the following years, he applied his programming and DSP expertise to other interesting areas including sonar and underwater acoustics.
Richard holds an MSEE degree from Southern Methodist University and has many years of experience in the application of computer technology to real-world problems.
