*** New Project Structure in GWT 1.6 ***
One of the biggest changes to GWT 1.6 is a new project structure. The old
output format has been replaced by the standard Java web app expanded „war“
format, and the actual directory name does default to „/war“. Note that the
war directory is not only for compiler output; it is also intended to
contain handwritten static resources that you want to be included in your
webapp alongside GWT modules (that is, things you’d want to version
control). Please also note that the „GWTShell“ and „GWTCompiler“ tools will
maintain their legacy behavior, but they have been deprecated in favor of
new „HostedMode“ and „Compiler“ tools which use the new war output. When 1.6
is officially released, we will be encouraging existing projects to update
to the new directory format and to use the new tools to take advantage of
new features and for compatibility with future GWT releases.
The sample projects provided in the GWT distribution provide an example of
correct new project configurations. For more details on the specifics of the
new project format, please see GWT 1.6 WAR design document (
http://code.google.com/p/google-web-toolkit/wiki/WAR_Design_1_6).
A couple of important changes we should highlight here:
– Projects with server-side code (GWT RPC) must configure a „web.xml“ file
at „/war/WEB-INF/web.xml“. This web.xml file must define and publish any
servlets associated with the web application. See the included DynaTable
sample. Additionally, server-side library dependencies must be copied into
„/war/WEB-INF/lib“. For example, any GWT RPC servlets must have a copy of
gwt-servlet.jar in this folder.
– HTML host pages will no longer typically be located in a GWT module’s
public path. Instead, we’ll be recommending that people take advantage of
the natural web app behavior for serving static files by placing host pages
anywhere in the war structure that makes sense. For exmaple, you might want
to load a GWT module from a JSP page located in the root of your web app. To
keep such handwritten static files separate from those produced by the GWT
compiler, the latter will be placed into module-specific subdirectories. Any
page that wishes to include a GWT module can do so via a script tag by
referencing the GWT-produced „<module>.nocache.js script“ within that
module’s subdirectory. As of 1.6, we’ll be recommending that only
module-specific resources used directly by GWT code, such as image files
needed by widgets, should remain on the public path. See the included
Showcase sample for some examples of this distinction.
– When you do need to load resources from a module’s public path, always
construct an absolute URL by prepending GWT.getModuleBaseURL(). For example,
‚GWT.getModuleBaseURL() + „dir/file.ext“‚. This advice has not changed, but
in the past it was easy to be sloppy with this, because the host page and
GWT module typically lived in the same directory, so using a relative URL
would usually do the right thing. Now that GWT modules live in a
subdirectory, you must reference public resources through
GWT.getModuleBaseURL().
*** Hosted Mode Enhancements ***
Although the legacy GWTShell still uses an embedded Tomcat server, the new
HostedMode runs Jetty instead. There is also a new „Restart Server“ button
on the main hosted mode window. Clicking this button restarts the internal
Jetty server, which allows Java code changes to take effect on the server
without having to completely exit and restart hosted mode. This is useful
when making code changes to RPC servlets, or when serializable RPC types are modified and the server and client are out of sync.
*** New EventHandler System ***
Event handlers have been added to replace the old event listeners used by
Widgets, History, and various other classes. The new system has a few
differences from the old system:
– EventHandler methods always take a single parameter: the GwtEvent that the Widget fired. For example, ClickHandler has a single method
onClick(ClickEvent).
– Each GwtEvent contains accessors relevant to the event, such as the key
that was pressed on KeyEvents. Native events provide access to the
underlying native event object.
– Each EventHandler defines only one method, so you do not need to create
empty methods just to satisfy the interface requirements.
For users who create their own Widgets, you no longer need to manage
listeners manually. Every Widget has a HandlerManager that manages all of
its handlers. For native events, such as ClickEvent, just call
addDomHandler() from within your code to register a handler and sink the
associated event on the Widget. When the native event is detected, the
handler will automatically be called. For logical events, such as
SelectionEvent, call addHandler() and fire the event manually using the
fireEvent() method.
You can see examples of EventHandler usage in many of the updated GWT
widgets and samples, or in new projects created with the new webAppCreator tool.
You can now trigger a native event on almost any Element. Create a new
native event using the Document.create*Event() methods, then dispatch it on a specific Element by calling Element.dispatchEvent(). These methods allow you to expand your test coverage in ways that were previously impossible.
*** New Widgets ***
DatePicker
The new DatePicker and DateBox widgets allow your users to select a date
from a calendar. The Showcase sample provides examples of both of these
widgets.
LazyPanel
The new LazyPanel widget allows you to delay the creation of certain
sections of your application until they are first accessed, improving
startup performance. For example, if your application has a seldom used
„Help“ section, you can wrap it in a LazyPanel and create the user interface
only if and when the user tries to access it. To use the LazyPanel, extend
the class and override the abstract createWidget() method. The
createWidget() method will be called the first time you call setVisible() on
the LazyPanel.