Автор

Неизвестен

Источник

http://developerlife.com/tutorials/?p=80

What is GWT?

Writing browser based AJAX (Asynchronous JavaScript and XML) web applications can be very tedious and requires in depth knowledge of both JavaScript, and myriad browser quirks and incompatibilities. The Google Web Toolkit (GWT) is an open source framework that allows Java developers to easily develop AJAX web applications without learning the ins and outs of JavaScript and browser development.

GWT provides a Java API that lets you build component based GUIs while avoiding JavaScript, and abstracting the HTTP protocol and underlying browser DOM model. All of this achieved using the GWT compiler, which does not generate Java bytecode, rather it generates JavaScript! The GWT compiler takes your client side Java code and generates JavaScript. A compiled GWT application consists of fragments of HTML, XML and JavaScript. If you want to have your web application communicate with a web server, GWT has you covered as well. GWT has a Remote Procedure Call (RPC) mechanism that makes it easy for the client and server to pass Java objects back and forth.

GWT also helps to enables developers to effectively test and debug their applications without first compiling them into JavaScript, and deploying the applications to a web-server. GWT allows applications to be run in what is called “Hosted Mode”. In “Hosted Mode”, a JVM executes your GWT application code as Java bytecode inside of an embedded browser window. Running GWT applications in “Hosted Mode” makes debugging your GWT applications very easy. Once you have tested your GWT application in “Hosted Mode”, you can compile your Java source code to JavaScript and deploy your application. GWT applications that have been deployed are said to be running in “Web Mode”.

So, in short, you write your application’s client and server side pieces in Java, and the GWT compiler will convert your client Java classes into browser compliant JavaScript and HTML. You deploy this JavaScript and HTML to your web servers, so end users will only see the web mode version of your application, while the server side classes can be deployed on Tomcat or any Servlet container of your choosing.

The goal of this tutorial is to help Java developers with little knowledge of web development learn how to develop web applications using GWT. Once you are done with this tutorial you should have the skills to build complex and fully functional GWT applications.

GWT Primer – things to know before getting started

GWT Browser Support

As of GWT version 1.4, GWT supports the following browsers:

The GWT Compiler

The GWT compiler converts Java source code into JavaScript. The GWT compiler supports most of the Java language and emulates a subset of the Java runtime library.

Language support

As of GWT version 1.4, the GWT compiler can compile source code that is compatible with J2SE 1.4.2 or older.

The GWT compiler:

Runtime Library Emulation

GWT provides a JRE emulation library. This library does NOT emulate all the J2SE and J2EE classes.

Java regular expressions aren’t completely supported in GWT. If you are going to use regular expressions in your GWT application, you need to ensure that you only use Java regular expressions that have the same meaning in JavaScript.

Find out more about Java regular expressions Find out more about JavaScript regular expressions

The GWT JRE emulation library does not support Java Serialization. In its stead however, GWT has and RPC facility that provides automatic object serialization. This RPC facility allows client-side code to make remote method calls and pass GWT serialized objects as parameters.

To find out more about the GWT compiler check out this article.

Client Side Code

GWT web applications are made up of two distinct pieces. The piece of your application that is sent across the network to a user, where it runs as JavaScript inside of a web browser, is referred to as client-side code. When writing clientside code it is important to keep in mind that this code will ultimately be turned into JavaScript. So make sure to only use libraries and Java language constructs that can be translated.

Server Side Code

The piece of your application that runs on a server computer is referred to as server-side code. Your GWT application might need to interact with your server, e.g. to load or save some data. In order to do this, the application makes a client-side request (from the browser) using GWT’s RPC mechanism. While processing the RPC call, server-side code is being executed. In GWT, client-side code compilation is not dependent on server-side code. As a result, you’re server-side code does not have any of the limitations that are imposed on the client-side code and you are free to choose whatever technology you want to use in your server-side code.

Deferred Binding

Deferred Binding is one of the key features that lets GWT produce well-optimized JavaScript code. As you saw earlier, the GWT compiler doesn’t support Java Reflection or dynamic class loading (also referred to as dynamic binding). This is because the JavaScript environment in which GWT applications run in doesn’t support it. Because dynamic binding is unavailable to GWT, GWT instead uses something called deferred binding. Deferred Binding is similar to dynamic class loading. While dynamic class loading occurs at runtime, Deferred Binding occurs at compile-time.

When the GWT Compiler compiles your client-side code, it determines all of the different “browser idiosyncrasies” it must support, and generates a separate, highly optimized version of the application for every specific configuration. So at the end of the day the compiler will generate a different version of your application for each different supported browser. But there is more to Deferred Binding than just multi-browser detection and support. Deferred Binding is a fully generic mechanism for handling context sensitive features..

.no-cache.js File

The “nocache.js” file is where Deferred Binding occurs. Before your GWT application can run, any dynamically-bound code must be resolved. This might include browser-specific versions of classes, Internationalization strings for the user’s selected language, etc. The “nocache.js” file includes a lookup table that maps Deferred Binding permutations to .cache.html filenames, e.g. “Firefox in German” and “Safari in English” would both be entries in the lookup table, pointing to different .cache.html files.

The file is named “.nocache.js” to indicate that it should never be cached, i.e. it must be re-downloaded and executed each time the browser starts your GWT application. The file must be re-downloaded each time is because the GWT Compiler regenerates it each time, but under the same file name. Allowing browsers to cache the file, would result in browsers not always downloading the latest version of the file when your application is recompiled and redeployed.

.cache.html Files

These are the files that actually contain your GWT application’s logic. A .cache.html file contains JavaScript code wrapped in a thin HTML wrapper. The GWT Compiler doesn’t simply output JavaScript (.js) files because certain browsers, under certain circumstances, do not properly handle compression of pure-JavaScript files. Wrapping the JavaScript in an HTML file solves the problem, and allows the GWT’s JavaScript output to be compressed.

Each .cache.html file uses the MD5 sum of its contents as its name. This guarantees deterministic behavior by the GWT Compiler. If you recompile your application without changing code, the output JavaScript code will not change, and so the MD5 sums (and the file names) will not change. If you do change your source code, the output JavaScript code will also change, and so the MD5 sums (and the file names) will change. Since these files will always have unique names, it is safe for browsers to cache them, hence the name “cache.html“.

.gwt.rpc File

As of GWT version 1.4, types that implement the java.io.Serializable interface now also qualify for serialization over RPC, but only if they are included in the .gwt.rpc file generated by the GWT compiler. The .gwt.rpc file serves as a serialization policy and indicates which types implementing java.io.Serializable are allowed to be serialized over the wire.

HTML Host Pages

Now that you know what the GWT compiler does and what it outputs (a bunch of JavaScript files) you might be wondering how any of this can be displayed in a web browser. This can be done by using a “Host Page”. Any HTML file with the proper set of tags can be used to display your GWT application.

Further reading in related categories

Managing GWT History and Hyperlinks Tutorial

When you are building GWT apps, that run in the context of a web browser, what should happen when the user of your app presses the Back or Forward button in their browser? GWT provides a way for your apps to hook into the browser's history mechanism, so that you can control what happens when a user hits Back or Forward in their browser. You can also programmatically manipulate the browser's history, and even create hyperlinks in your apps that can hook into the browser's history mechanism. You can even intercept these hyperlinks when a user clicks on them, instead of having the browser handle it, or both. This tutorial will show you how to leverage GWT's history mechanism and do some creative things with histories and hyperlinks that will be useful in your applications.

Deploying GWT Apps Tutorial

There are two aspects to deploying a GWT application: client side deployment, and server side packaging and deployment. In this tutorial, I will cover the different sets of issues that are tied to each aspect of deployment and packaging. Issues around cross site scripting, integration into existing webpages/apps, deployment as widgets, and much more are discussed in detail.

Using Servlet Sessions in GWT - Tutorial

Because GWT web applications run inside of a browser, they are limited to making requests over HTTP. HTTP is a “stateless” protocol and it doesn’t provide any facilities for tracking previous transactions. In this tutorial you will learn how to use GWT’s RPC mechanism, specifically the RemoteServiceServlet, to enable session support in your GWT application.

Using and creating GWT modules Tutorial

If you are trying to build a complex GWT application that needs to be split into multiple modules, or if you need to import 3rd party modules into your application, this tutorial will show you how to do both of these things. We will import the GWT Log module, and we will also create a new module that you can include as a dependency for other modules/projects.

Create GWT “Hello World” with IDEA Tutorial

In this tutorial, I will walk you through the tasks you need to perform in IDEA 7 to create GWT projects. We will do the following: create a new project, add resources to it (images, stylesheets), create a web facet for deployment to an app server/servlet engine, add a loading screen for your app.

Transport Objects over RPC – GWT Object Serialization - Tutorial

This tutorial will teach you how to create and use Serializable objects that can be transported over GWT's RPC mechanism.

Building a GWT RPC Service - Tutorial

One of the most important pieces of the GWT framework is the GWT Remote Procedure Call (RPC) mechanism. This RPC mechanism makes it easy for a GWT application client to make a call to server-side code. GWT RPC makes it simple to get data between the client and the server. The server-side code that gets called from the client is referred to as a service. This tutorial will teach you how to build a GWT RPC Service.

Anatomy of a GWT Project - Tutorial

The first step in writing any GWT application is setting up a GWT Project. This tutorial will introduce you to the ins and outs of GWT projects.