The Great GWT Roundup
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
[img_assist|nid=5211|title=|desc=|link=none|align=right|width=113|height=105]Over the past two months or so we here at the web builder zone, thanks to Manning Publishing, have been publishing a comprehensive series on GWT. We recently published the last in the series and I thought that it would be a good idea to create a sort of index of all of these articles.
So if you missed the series, missed an article or want to explore the series again this is your chance. Below is a summary of each article posted with a direct link to the complete article.
The core of every GWT project is the project layout and the basic
components required—host pages, entry points, and modules. To begin a
GWT project, you need to create the default layout and generate the
initial files. The easiest way to do this is to use the provided
We have a calculator EntryPoint implementation that places a CalculatorWidget on the RootPanel, so we now need to provide this widget. This will be our own widget, composed of basic GWT components. CalculatorWidget will contain the view for our calculator application, a simple data and logic layer as the model, and an intermediary controller between these layers. This, of course, means we'll be using MVC and GWT together - keep in mind that all of these components will end up distributed to the client.
GWT enables client applications to communicate with server resources through its own RPC and object-serialization mechanism. This communication process involves each side of the conversation implementing a very straightforward GWT service interface and sending/receiving special GWT serialized data. The server side exposes resources, and the client side invokes those resources asynchronously.
The GWT shell uses a stripped down and somewhat customized version of the Apache Tomcat servlet container as its development mode server. While this is a Tomcat instance, GWT sets things up differently to automate certain elements and facilitate quick and easy development mode use and testing.
GWT's deployment of applications to the local Tomcat can be somewhat confusing. Saying that GWT uses Tomcat is much like saying that your favorite driver drives a Camaro in NASCAR races. It might look like a Camaro, people might even call it a Camaro, but driving it's not like driving the Camaro your local GM dealer will sell you. GWT's Tomcat has a custom deployment descriptor, web.xml, which includes the configuration for the special GWTShellServlet. This servlet is used in hosted mode only to automatically dispatch servlet entries from your module file into the appropriate classes.
GWTShell includes the -noserver command-line option, which instructs the toolkit not to start or use the embedded Tomcat instance. If you use -noserver, you're essentially telling GWT that you'll handle the server-side resources on your own, like a baseball player in the outfield calling a fly ball - "I got this one."
The model layer of a GWT application has to be a little bit smarter than the model in many traditional web applications. It needs to be responsible for notifying the view layer of changes, as well as for receiving updates to its own structure. In desktop Java development, this is accomplished through the use of PropertyChangeEvents and PropertyChangeListeners that bind the data from the model to the view components. The view layer "listens" for changes to the model and updates itself accordingly, using the Observer pattern. This can be done in GWT development as well. Figure 1 shows a basic User class that we will work with.