This article is based on GWT IN Action, Second Edition (buy from amazon), published on May 2011. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) eBooks and pBooks. MEAPs are sold exclusively through Manning.com. All pBook purchases include free PDF, mobi and epub. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information. [ Use promotional code 'java40beat' and get 40% discount on eBooks and pBooks ]

Introduction

One of the main selling points of GWT is that it allows you to use an industry-grade language, with an industry-grade set of tools, to build…well…industry-grade web apps. But, as with any large scale development project, you can easily paint yourself into a corner. Far too many times when building GWT-based apps, we find ourselves slinging code wherever necessary to make the app work, and (sometimes more importantly) look good.

Fortunately, there is a well known solution to this problem: build your applications based on the model-view-presenter (MVP) paradigm.

Architecting your GWT-based apps to utilize the Model View Presenter (MVP) paradigm provides the foundation and rails necessary to avoid some common pitfalls.

Let’s see first how the user sees the application and then what we will be doing from the MVP perspective.

From the user’s perspective

Figure 1 shows the screens that can be found in our sample photo application.

Our photographer seems to have been in one of their abstract moods for this photo set because these are all just blocks of color. You can click on one of the photos, and a larger version is shown on its own, and here you can edit the title through an editable label where the new title is saved back to the server, if requested.

It really is a nice way to see the underlying implementation using MVP.

From the MVP perspective

At its core, MVP is a design pattern that breaks your app up into the components listed in table 1, the right-hand column of which explains how this is done for PhotoApp.

Table 1 Components of the MVP paradigm

The concept is that a presenter creates its associated view and requests the view to be populated with appropriate data from the model. When UI elements in the view are updated, they notify the presenter to change the model. This way, the view doesn’t need to know about the model, making it easy to swap and maintain.

A quick note on connecting views and presenters

The more contemporary MVP setup you may have read about in previous articles, blog posts, and so on, would indicate that presenters register to receive events raised from the view’s widgets.

However, you will see that we specifically make the presenter register itself in the view, and that the view notifies the presenter by calling appropriate registered presenter methods when events are raised.

Navigation to a new view is performed either by the application updating the URL in the browser as a result of the user doing something, or the user clicking the forward/back buttons. The application will react to changes in the browser’s URL and creating the appropriate presenter (which then creates the view). We will call this the Application Controller or AppController for short.

We will also make use of an EventBus. We’ll use this to raise application-wide events. To keep to the MVP paradigm, we need to be careful that these events do not cause changes in the model. What is their use then? Well, in our application we will allow various presenters to raise ApplicationBusy and ApplicationFree events, for example, when starting and completing communication with the server. These events will be dropped onto the EventBus by the presenters, and the AppController will listen for them and react by showing and hiding a busy message.

Using a ClientFactory

Throughout the two photo app projects, you will see us use a ClientFactory object. It will provide access to singleton instances to common objects across the application. For example, it provides access to our views as singleton objects, and this improves efficiency because views contain DOM calls, which are expensive.

There’s no requirement to use a ClientFactory in the MVP paradigm, but it is helpful if we are thinking of enterprise-wide development.

Between a presenter and its view, there is a strong connection, but loose coupling. Nice words, but what does it mean? Well, let’s crack open some of the photo apps code and have a look.

Creating Views

Remember that our view should have no application logic in it, at all. It should be just UI components that the presenter can access to set or get values from.

All of our views will be implemented as three separate items: a generic interface, a specific interface and an implementation. The next three sections will look at each of those in turn, starting with the generic interface.

The root of all views

Each of our views will be built upon a basic interface that we will call View. This is not a requirement to have, but suits us well as it creates a basic contract that all our views will adhere to, and that other components are aware of and can trust. Here it is:

1
2
3

public interface View extends IsWidget{
		void setPresenter(PhotoDetailsPresenter presenter);
	}

There are two key things to note about this interface. Any implementation must implement the setPresenter method – which allows the presenter to register itself with this view (this is the topic of section 14.1.3 so we will leave that for now). The other is that all our views will extends the IsWidget interface. This means each view will implement the asWidget method, which we will have to implement so that it returns a representation of the view that is a widget. Luckily, since most views will be made up from a Composite which, from GWT 2.1 onwards, already implements asWidget, we are good to go with no extra work!

Each specific view needs to be described individually, and for that, we create first a new interface.

View specific interface

For each view we will have, we create a new interface that extends View. These view specific interfaces define the methods that a presenter can call to get access to the UI components. As an example, our PhotoDetailsView will have a title that can be changed and so the value of needs to be retrieved. We can make the interface show that by saying it must implement a getPhotoTitle method that returns an object implementing the HasValue<String> interface:

1
2
3

public interface PhotoDetailsView extends View {
		HasValue<String> getPhotoTitle();
	}

Our application has three views, so you can find the three interfaces in the source code, for example in the com.manning.gwtia.ch14.client.mvp.views package.

With the details of the views now specified in the interfaces, we need to implement them.

Implementing the views

Our view specific interfaces detail exactly what can be expected from the view. But without an implementation, they are not going to do much!

It turns out that our implementation of the PhotoDetailsView interface is pretty simple. That should be as expected as the view is dumb and contains no logic. The first two chapter examples are the same, except they differ in how views are implemented. In the first example, the implementations are verbose as we have a lot of boilerplate code; in the second, we have swapped the view implementation for UiBinder versions.

The only difference between the two versions is the use of UiBinder, and therefore how we bind events to actions. The actual actions do not change. Take the detailed view, each implementation implements the setPresenter method to register the parameter as this object’s presenter:

1
2
3

public void setPresenter(PhotoDetailsPresenter presenter) {
		this.presenter = presenter;
	}

Each view also implements a reaction to the title being changed. In the UiBinder approach it is neatly described as follows

1
2
3
4
5
6

	@UiHandler("title")
	public void changeTitle(ValueChangeEvent<String> event) {
		if (presenter != null){
			presenter.onUpdateTitle();
		}
	}

In other words, if the title widget raises a ValueChangeEvent, then as long as the presenter is not null, call the presenter’s onUpdateTitle method.

In the non UIBinder project, the same logic is there, but it is implemented by manually creating the title object and then adding a ValueChangeEvent handler to it. By convention, we tend to put all the binding code in a bind() method, if we are not using UIBinder.

So, our view is dumb and contains zero application logic. That is because we agreed that all of that should appear only in the presenter. And this brings us to the discussion of those presenters.

Presenters

Presenters are where all the application logic sits and will have no UI components. (Those are all in the view, as we’ve just seen.) In a similar way to views, we provide a generic presenter interface, a specific one, and an implementation for each presenter.

The root of all presenters

Just like views, we will create a basic interface that all of our presenters will implement. Again, there is no requirement to do this; it is just good to have. Here’s our basic interface:

1
2
3
4

public interface Presenter{
		public void go(final HasWidgets container);
		public void bind();
	}

The go method takes the widget in which we wish the presenter-associated view associated to be displayed. All we require of that widget is that it implements the HasWidgets interface; in other words, it is a panel of some kind.

A presenter will also implement a bind method. In our design, this is where the presenter will listen to any application-wide events it is interested in (for example, this is where it hooks into the event bus) as well as where it calls the associated views setPresenter method.

Each view will have an associated specific interface.

Presenter-specific interface

The specific functionality of the view is given in a new interface that implements Presenter.

In the specific presenter interface we wish to declare those methods that will be called from the view when things happen. Remember that we said the view is responsible for reacting to UI events within itself, but that it will then call methods on the presenter that was registered with it for the actual business logic. Here, we see the PhotoDetailsPresenter interface relating to the title:

1
2
3

public interface PhotoDetailsPresenter implements Presenter{
		public void onUpdateTitle();
	}

What we are saying here is that we expect the onUpdateTitle method to be called when the title is updated in the view. We would add other methods to the interface based on the other UI components that are of interest.

Now we have the specific presenter interface in place, we should implement it.

Implementing specific presenters

Our presenters are just implementations of the specific presenter interfaces. For example, PhotoDetailsPresenterImpl implements the PhotoDetailsPresenter interface.

This means it needs to implement the go and bind method from Presenter as well as the onUpdateTitle from PhotoDetailsPresenter. Listing 1 shows the skeleton of our implementation.

Listing 1 PhotoDetailsPresenter

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public class PhotoDetailsPresenterImpl implements PhotoDetailsPresenter {
private ClientFactory clientFactory = GWT.create(ClientFactory.class);
public PhotoDetailsPresenterImpl(final PhotoDetailsView photoDetailsView
, final String id) {
this.rpcService = clientFactory.getPhotoServices(); |#1
this.eventBus = clientFactory.getEventBus(); |#1
this.photoDetailsView = photoDetailsView; |#1
eventBus.fireEvent(new AppBusyEvent()); #2
rpcService.getPhotoDetails(……) #3
bind();
}
public void bind() {
photoDetailsView.setPresenter(this); #4
}
public void go(final HasWidgets container) { |#5
container.clear(); |#5
container.add(photoDetailsView.asWidget()); |#5
} |#5
public void onUpdateTitle() { |#6
rpcService.savePhotoDetails(……); |#6
} |#6
}
#1 Getting shared resources
#2 Firing application wide event
#3 Making a server call
#4 Binding to other items
#5 Implementing the go method
#6 Called from View when title updated

The first thing that is done in the constructor is to get hold of some common resources from the ClientFactory that we previously mentioned. This is not a requirement but makes our lives easier. For example, we grab resources such as the RPC service and the event bus—we might as well share the RPC service for efficiency, and we have to share the event bus; otherwise, it would not be system wide.

Once we have grabbed our resources from the factory, we make a call to get the details of the photo just after we have fired off a system-wide ApplicationBusy event. The intention here is that some other component will inform the user that the application is busy in some way—we don’t care at this point how that is done. Not shown in listing 1 is the fact that an ApplicationFree event is fired within the RPC return handling code so that the user is notified the application is no longer busy.

Within the constructor, we also call the bind method from the Presenter interface. For this implementation, that simply calls the view’s setPresenter method to register this view with that presenter. Other implementations may register on the event bus if it has to handle application wide events.

In #5, we are implementing the Presenter’s go method. This clears the container widget passed in as the parameter and then adds the associated view as a widget. In the application controller, we will create presenters in the following manner:

1

new PhotoDetailsPresenterImpl(clientFactory.getDetailsView()).go(container)

Where container is the widget that we wish the presenter to present in the view.

That’s it really for the views and presenters. Just before we jump to the AppController, which is responsible for tying everything together and starting presenters, we want to take a little deeper look at the relationship between presenter and views we have used.

The two-way presenter/view relationship

At the heart of the MVP pattern is the relationship between your presenters and views. Presenter classes should contain all of your complex application logic, and no widget code/references. Completely inverse to that, your views should contain nothing more than widgets, and should avoid any application logic wherever possible.

Why? For two reasons: 1) fast testing with increased code coverage and 2) maximum code reuse when porting to other Java based platforms, for instance Android (written carefully in the MVP paradigm, the application logic of a GWT application can be reused and all you need to do is just replace the view component).

If you look at testing, enforcing this split between presenters and views offers another way to save more time/money/development frustration. Whenever you find yourself needing to test functionality within your app that relies on widgets or some Javascript Native Interface (JSNI), you’re going to need a browser context. This means you’re going to need to run it within a GWTTestCase, which means—you guessed it—it’s going to take a long time to run that test. So how do we fix this? Simple. Let’s not test them at all—if you make the view as dumb as possible, by moving all of your app logic out into the presenter, you should be left with a view that contains nothing more than GWT widgets. Given that these are continuously tested by the GWT team, doing so in our own tests is simply redundant and not required. And, where you do need to test your views, those tests should be few and far between and, in many instances, simply integration testing being driven by Selenium (or some Selenium-like testing suite).

Now that we agree on moving the app logic out of the view, we have to move the view logic out of the presenter. More specifically, we have to make sure our presenters are solely relying on plain old Java code. This is to ensure that they can be tested using a vanilla JUnit test (which runs in ~1/1000th of the time of a GWTTestCase).

But, we are also making the relationship between view and presenters slightly differently to what you might expect. The more contemporary MVP setup you may have read about in previous articles, blog posts, and so on, would indicate that presenters register to receive events from the view’s widgets.
However, you can see in the code above, we specifically make the presenter register itself in the bind method with the view via the view’s setPresenter method, and that the view listens for events and then calls the appropriate method in the presenter.

Up until now we have views and presenters for our PhotoApp, but we have no way of knowing what presenter to request (so no idea what view to show), or react to the user changing views. For that, we need to control the application.

Controlling the application

We need a mechanism to change views in our application. The most common one is to indicate in the browser URL the new view required, usually via a token on the URL, and then to react to that.

In our presenters, if a view change is needed, we will change the history token to an appropriate value. This happens, for example, when selecting a photo in the Photo List view. The click on a photo is registered in PhotoListViewImpl, which then calls back to the presenter saying which photo is selected. In the PhotoListPresenterImpl code, we have:

1
2
3

public void onSelectPhotoClicked(String id) {
History.newItem(Tokens.DETAIL + "&" + id);
}

All we are doing here is changing the history token to have a value defined in the Tokens class to represent Photo Detail view appended by the photo id the user is interested in. If we’re interested in photo number 00004, then our development mode URL becomes as shown in figure 2.

Listing 2 AppController showing bind() to History and other events

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class PhotoAlbumApp implements ValueChangeHandler<String> { #1
	private void bind() {
		:
		History.addValueChangeHandler(this); #1
		}
		public void onValueChange(ValueChangeEvent<String> event) { |#2
		String token = event.getValue(); |#2
		if (token != null) { |#2
		if (token.startsWith("details")) |#2
		doPhotoDetailsDisplay(token); |#2
		else if(token.startsWith(”list”)) |#2
		: |#2
		} |#2
	} |#2
	private void doPhotoDetailsDisplay(String token){} |#3
	private void doPhotoListDisplay(String token){} |#3
	private void doWelcomeDisplay(String token){} |#3
}
#1 Implementing the History Management
#1 Binding events to actions in the code
#2 Handling history changes
#3 Changing the view

The AppController binds itself to listen to listen to history events in #1 by implementing the ValueChange interface as well as adding this object as the ValueChangeHandler in the History.

We must implement the onValueChange method (#2), which is called when the history changes by GWT’s history subsystem. This method we set up to simply parse the history token to determine what view is requested, and then is required, and will call one of the do methods in #3, if the history token is recognized and an action can be determined.

These do methods are responsible for creating the view and the presenter, and then calling the presenter’s go method. For example, if we have changed to the situation in figure 2, then the onValueChange method determines that the value detail means it needs to call the doPhotoDetailsDisplay method. This action shows the user the new photo details view with the requested image, while the AppController sits there waiting for the next history change.

Summary

The MVP pattern is extremely useful when building large, web-based applications with GWT. Not only does it help make code more readable, and subsequently more maintainable, it also makes it much easier to implement new features, optimizations, and automated testing. Speaking from experience, we can’t stress the testing benefits enough. It’s a fundamental part of writing real-world applications, but often times it’s overlooked because it’s left until the end, and is too much of a pain to integrate. When your app is developed using the MVP pattern, test cases are a piece of cake, so much so that you’ll want to write them first. Remember, test driven development is your friend.

This article is based on GWT IN Action, Second Edition (buy from amazon), published on May 2011. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) eBooks and pBooks. MEAPs are sold exclusively through Manning.com. All pBook purchases include free PDF, mobi and epub. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information. [ Use promotional code 'java40beat' and get 40% discount on eBooks and pBooks ]

Introduction

With GWT v2, it is going to be a rare occasion where you need to create a widget directly from the Document Object Model (DOM). This is because GWT 2.0 covers nearly all the widgets we can think of. If you are using a GWT version lower than 2.0 then you may find some things missing (such as a widget wrapping the SPAN element—GWT 2.0 provides InlineLabel, which does that).

We will look a little into the future and show how to implement a Canvas widget. (You can tell GWT is quite swift moving because GWT 2.2 now provides this type of widget, but we will stick to creating it ourselves to explore some of the points related to creating a widget from the DOM.) A canvas element in HTML allows us to draw two- dimensional objects and bitmaps on the browser screen. Figure 1 shows an example of our Canvas widget in action as it draws a square on the screen.

Listing 1 An example Canvas widget

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

package org.gwtbook.client;
import com.google.gwt.core.client.JavaScriptObject;
import com.google.gwt.dom.client.Document;
import com.google.gwt.dom.client.Element;
import com.google.gwt.user.client.ui.RootPanel;
import com.google.gwt.user.client.ui.Widget;
public class Canvas extends Widget { #1
public Canvas() { #2
Element element = Document.get().createElement("canvas");
setElement(element);
setStyleName("canvas-style");
context = getCanvasContext(element);
}
protected Canvas(Element element) { #3
setElement(element);
assert element.getTagName().equalsIgnoreCase("canvas");
}
public static Canvas wrap(Element element) { #4
assert Document.get().getBody().isOrHasChild(element);
Canvas canvas = new Canvas(element);
canvas.onAttach();
RootPanel.detachOnWindowClose(canvas);
canvas.context = canvas.getCanvasContext(element);
return canvas;
}
JavaScriptObject context;
public native void fillRect(int top, int left,
int width, int height)/*-{
this.@org.gwtbook.client.Canvas::context.fillRect(top,left,
width,height);
}-*/;
public native void fillStyle(String fillStyle)/*-{
this.@org.gwtbook.client.Canvas::context.fillStyle = fillStyle;
}-*/;
protected native JavaScriptObject getCanvasContext
(Element element)/*-{ #5
return element.getContext('2d');
}-*/;
}
#1 Extending the Widget class
#2 Creating a new Widget
#3 Private constructor
#4 Wrapping an existing canvas element

Widgets will extend the Widget class (#1). Most GWT widgets contain two ways to create them: a public constructor used for creating a new widget (#2) from scratch and a protected constructor that creates a widget from an existing element in the DOM (#3).

When creating a new widget, there are generally three steps. First, we create the DOM element. At #2, we use Document.get().createElement(”canvas”)) to create a canvas element. Then, we call the Widget class’s setElement method to bind the element to the widget. After this, we set a style name for the widget. For this widget, we chose the base style name canvas-style.

Typically, a widget would now be complete and ready for use. In our case, we need to take an extra step to get the canvas’s 2D context which is used in later drawing methods. We do that by calling getCanvasContext method, defined at #5 using JSNI.

With everything defined, creating the square in figure 1 in a browser that supports canvas can be created using:

1
2
3
4
5

Canvas c = new Canvas();
	c.setPixelSize(400, 400);
	RootPanel.get().add(c);
	c.fillStyle("rgb(80,255,80)");
	c.fillRect(10, 20, 100, 50);

This code creates a new Canvas widget instance, sets its size, adds it to the RootPanel, and then uses two specific methods we defined in the widget to set the fill style and draw the rectangle.

If we had the following HTML in the body of our application’s HTML file

1

<canvas id="demo-canvas" width="400" height="400"></canvas>

Then we could use the wrap method to create the widget. We get the same result as figure 1 using the following code instead of the code above.

1
2
3

Canvas c = Canvas.wrap(RootPanel.get("demo-canvas").getElement());
	c.fillStyle("rgb(80,255,80)");
	c.fillRect(10, 20, 100, 50);

The wrap method in listing 1 (#4) is copied here.

1
2
3
4
5
6
7

public static Canvas wrap(Element element) {
		assert Document.get().getBody().isOrHasChild(element); #1
		Canvas canvas = new Canvas(element); #2
		canvas.onAttach(); #3
		RootPanel.detachOnWindowClose(canvas); #3
		return canvas;
	}

It first asserts the element passed as the argument is attached to the DOM (#1). If it is, then it calls the protected Canvas constructor (#2), which binds the element to the widget and asserts that it is indeed a canvas element. Once the widget is constructed, we need to manually call two housekeeping methods that GWT would normally call for us (#3).

Because the widget is already attached to the DOM, then we need to call the widget’s onAttach method ourselves to link it into GWT cradle. We also need to manually register the widget with the RootPanel’s detachOnWindowClose method so it is removed safely if the browser window is closed.

Our widget is effectively complete. You could extend it further to implement other canvas functionality, and perhaps use some deferred binding to cope with Internet Explorer’s lack of canvas implementation. We should, though, look at two other things—the functionality that the widget declared will implement and how events are handled.

Indicating functionality

There are a number of Java interfaces that a widget can implement to tell the world it has certain functionality. You don’t need to make your widget implement any of these interfaces, but it does help to adhere to the GWT style, and do so.

The HasText interface indicates the widget has some text, and that we can expect to be able to call the setText method to change that text and the getText method to retrieve the text value.

When you create a new widget, you should consider what interfaces the widget should implement. Some of these are shown in table 1 along with an indication of which package they are in to help you find others.

Table 1 An overview of some of the interfaces a widget can implement to provide indication of functionality.

For our canvas widget, there are no GWT interfaces we need to implement but, next, we’ll hook up an event and so use the HasMouseOverHandler interface.

Hooking up events

Hooking up events is simple. We introduce the appropriate HasXXXXXHandler interface, and then provide an addXXXXXHandler method that calls the addDOMHandler method. (Since our widget extends Widget, this is available to us.)

To show this in practice, let’s add the ability to handle mouse over events to our Canvas widget (see listing 2).

Listing 2 An example Canvas widget

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

package com.gwtbook.client.ui;
import com.google.gwt.core.client.JavaScriptObject;
import com.google.gwt.dom.client.Document;
import com.google.gwt.dom.client.Element;
import com.google.gwt.user.client.ui.RootPanel;
import com.google.gwt.user.client.ui.Widget;
public class Canvas extends Widget
implements HasMouseOverHandler { #1
public HandlerRegistration |#2
addMouseOverHandler(MouseOverHandler handler){ |#2
return
this.addDomHandler(handler, MouseOverEvent.getType()); #3
}
public Canvas() {
:
See listing 1 for rest of Canvas code
:
}
#1 Creating a new Widget
#2 Defining the BookBar class
#3 Wrapping an existing canvas element
 
Now, if we run our example code with a little addition—
 
 
final Canvas c = new Canvas();
c.setPixelSize(400, 400);
RootPanel.get().add(c);
c.fillStyle("rgb(80,255,80)");
c.fillRect(10, 20, 100, 50);
c.addMouseOverHandler(new MouseOverHandler(){
public void onMouseOver(MouseOverEvent event){
c.getElement().getStyle().setBackgroundColor(”lightblue”);
}
});

And put the mouse over the widget, we get figure 2 as the result.

Summary

We created a widget from scratch to represent a DOM element. We mentioned that it is unlikely you will have to do this because GWT already provides widgets for most DOM elements already.

This article is based on GWT IN Action, Second Edition (buy from amazon), published on May 2011. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) eBooks and pBooks. MEAPs are sold exclusively through Manning.com. All pBook purchases include free PDF, mobi and epub. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information. [ Use promotional code 'java40beat' and get 40% discount on eBooks and pBooks ]

Introduction

Back in 2006 when GWT was released, it solved a lot of the traditional problems for developing large JavaScript applications. So great was the promise that developers began to develop massive GWT applications—so massive, in fact, that they started hitting a wall. The wall they hit had to do with the size of the application.

If you think about your traditional desktop application like Microsoft Word, there are so many features of that application that you don’t normally use. For instance, the Mail Merge tool within Microsoft Word is extremely useful when you need that functionality, but most users rarely use it if at all. So the first question is how do we load only the functionality that will be used?.

Another common engineering issue was how to decrease the load time of the application. It is common for a feature full GWT application to approach a megabyte in size. With broadband, this is generally a fast download, but at the same time users have higher expectations that they did with their 56K modem. Users now judge the speed of your application in hundreds of milliseconds and not seconds. If your application takes a full second to start up, it may be considered as being sluggish. So how can you decrease the start time?.

This is where code splitting comes in. If you can cut your code into multiple segments, you can kill two birds with one stone. A smaller initial download means faster startup, and loading less-often accessed code only when it loads means smaller total downloads.

We begin our discussion by explaining the basics of using code splitting, then delve deeper and explore a coding pattern that has proven useful for segmenting your application.

Understanding code splitting basics

code splitting in theory is really very simple to understand. You wrap a piece of code in an asynchronous block, much like you would do with an RPC call, and let the compiler handle the rest. Let’s start with an example, listing 1, so that we can see what we are talking about.

Listing 1 An extremely simple example of code splitting

1
2
3
4
5
6
7
8
9
10
11
12
13

RunAsyncCallback callback = new RunAsyncCallback() { |#1
	public void onSuccess () { |#2
	doStuff();
	}
	public void onFailure (Throwable reason) { |#3
	Window.alert("Error: " + reason.getMessage());
	}
	};
	GWT.runAsync(callback); |#4
	#1 Creates callback
	#2 Defines success handler
	#3 Defines error handler
	#4 Loads and executes

This example literally covers the entire code splitting API. Even though it is extremely simple, let’s walk through the example and provide some commentary. As shown in the example, we first create a RunAsyncCallback instance (#1). RunAsyncCallback is an interface that is very similar to the asynchronous interfaces used by RPC, like AsyncCallback and RequestCallback, in that it has methods for handling success and errors.

The success handler onSuccess() (#2) is called when the JavaScript fragment, called a split point, is successfully loaded from the server and is ready to be run. This is also where the compiler determines where to split your code. Of course it, isn’t quite that cut and dry due to dependencies, which we will discuss shortly.

The error handler onFailure() [#3] is called when the split point fails to load. The typical cause of this would be because the network is not available or the site is not reachable. This could occur frequently for mobile users, where they might start using your application from a Wi-Fi hot spot, then trigger a split point after leaving the hot spot. Here, we simply show an alert pop-up, but it is probably a good idea to think about how your application should handle these errors.

Once the callback is defined, all we need to do is call GWT.runAsync() (#4) to trigger the loading and execution of the split point. In addition to loading the split point, there may also be some leftover code that also needs to be loaded. During compiling, there may be some code that doesn’t fit in a single split point and instead is shared across more than one. This is called leftover code and will be loaded prior to any split point code.

What is GWT.runAsync()?

To get your code split, simply insert calls to GWT.runAsync() at the places where you want the program to be able to pause for downloading more code. These locations are called split points.

For example, here is the initial, unsplit Hello sample that comes with GWT:

1
2
3
4
5
6
7
8
9
10
11

public class Hello implements EntryPoint {
	  public void onModuleLoad() {
		Button b = new Button("Click me", new ClickHandler() {
		  public void onClick(ClickEvent event) {
			Window.alert("Hello, AJAX");
		  }
		});
 
		RootPanel.get().add(b);
	  }
	}

To visualize this, add a few split points to a GWT application then compile the code and generate a Compile Report. You can turn on generation of the Compile Report add the compiler switch –compileReport.

An example of what you might see on the Compile Report if you had two split points is shown in figure 1.

If you just drop this into one of your own applications, it is likely you won’t see results quite as good as these. These results are from a simple test application where the initial download has relatively no functionality, and the code within the split points have no dependencies on each other. In fact, what you are more likely to see is something in figure 2.

Tracking down dependencies can be done using the Compile Report, but there is also a pattern we can rely on, the Async Package pattern.

Using the Async Package pattern

The intent of the Async Package pattern is to place collaborating classes within a Java package, then restrict access to classes within that package so that they can only be used asynchronously as a split point.

The motivation is that we want to create a split point that contains a particular segment of our code base, and we want to do so in a way that makes it difficult or impossible to create code dependencies that will cause the segmented code to be required by other segments. This is useful for development teams with multiple programmers, where you want to ensure that one developer can’t undo the work done by another. This is also useful for a single developer who wants to keep the application easy to maintain, so that enhancements added months from now don’t cause your split points to become dependent on each other.

If we were to boil this pattern to a recipe, it would consist of these bullet points.

• Isolate collaborating classes within a package.
• Remove all static methods.
• Create a single gateway class with a private constructor.
• Instantiate the gateway only within a GWT.runAsync() call.

The general idea is that all access to that package must first require the creation of the gateway class using GWT.runAsync(). By doing this, you ensure that your split point can’t be broken from users calling into the package. The first step in implementing this pattern is to isolate classes within a package from the outside world.

Isolating collaborating classes

Of course, we do this all the time in Java. We make use of keywords like protected and private to hide methods and fields from unrestricted use. By providing access where it is really needed, our code becomes inherently easier to maintain. A private method can always be renamed with the assurance that it won’t affect anything outside of the class. And the type of a protected field can be altered knowing that it only affects classes in the same package and subclasses.

The Async Package pattern makes use of Java’s access tools by restricting access to the set of classes that will become our split point. Locking down the classes in your package should be fairly straightforward for Java developers, so we won’t say much about that other than that you should make use of protected and default access to prevent outside access.

Ideally, you would plan out your split points ahead of time, but as with many things it isn’t always predictable ahead of time where it makes sense to split your code. So, if you have an application, you may wish to make use of a tool like JDepend1, which will analyze your application and report on dependencies between packages. If you are using Eclipse for your development, we recommend using JDepend4Eclipse2, which is shown in figure 3.

Now, once you have your grouped your collaborating classes in a package, it is time to create the gateway class.

Creating the gateway

Creating the gateway class involves creating a private constructor, creating an asynchronous factory method, and implementing any methods needed by the world outside of our package.

We present our example gateway class for a package that encapsulated functionality for driving a car in listing 2.

Listing 2 An example gateway class for the Async Package pattern

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

package com.manning.gwtia.ch18.client.car;
import com.google.gwt.core.client.GWT;
import com.google.gwt.core.client.RunAsyncCallback;
public class CarGateway {
private CarGateway () { }
public static void createAsync (final Callback callback) { |#1
GWT.runAsync(new RunAsyncCallback() {
public void onSuccess () { |#2
callback.onCreated(new CarGateway());
}
public void onFailure (Throwable reason) { |#3
callback.onCreateFailed(reason);
}
});
}
public interface Callback { |#4
void onCreated (CarGateway gateway);
void onCreateFailed (Throwable reason);
}
public void startEngine () { ... }
public void setSpeed (int mph) { ... }
public int getSpeed () { ... }
}
#1 Factory method
#2 Success handler
#3 Failure handler
#4 Callback interface

In listing 2, we have made the constructor private, forcing callers to construct the class using the factory method createAsync() (#1). The createAsync() method takes a single callback argument, which is an interface that we will define shortly. In createAsync(), we use GWT.runAsync(), which will create our split point.

In the onSuccess() method (#2), we make use of the callback argument, calling callback.onCreated() and passing back a new instance of CarGateway.

The callback.onFailure() method (#3) simply passes the exception back to the user. As stated before, this would typically be triggered if there was a network error where the split point can’t be loaded.

The Callback interface (#4), implemented by the parameter passed to our createAsync() method, is defined here as an inner class. We then provide some work methods that can be called, like startEngine() and getSpeed(), once the CarGateway instance has been constructed.

Creating a gateway class in this manner, where we force callers to use a factory method, means that the caller can’t get it wrong. We will look at some examples of that next.

Using the gateway class

From the client side, use of the gateway class is unrestricted now that it can only be created via the factory method createAsync(). Instead of looking at the simplest use case, let’s look at something you might find in the real world. Imagine that your application is pretty heavy and you want to present a splash screen as early as possible. This is akin to when you open a web application and it says “Loading”, like you might see on GMail.

The reason developers do this is so that user perceives the application as loading quickly. Your typical will perceive the speed of starting the application based on how long it takes you to render those first widgets, so it is useful to display some sort of splash screen while the full application code loads.

For our example, in listing 3, we will display a simple message “Loading car data…” and then replace that message with a button to start the car once the split point is loaded.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

package com.manning.gwtia.ch18.client;
import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.event.dom.client.*;
import com.google.gwt.user.client.Window;
import com.google.gwt.user.client.ui.*;
import com.manning.gwtia.ch18.client.car.CarGateway;
import com.manning.gwtia.ch18.client.car.CarGateway.Callback;
public class Main implements EntryPoint
{
private CarGateway carGateway;
public void onModuleLoad () {
RootPanel.get().add(new Label("Loading car data...")); |#1
CarGateway.createAsync(new Callback() { |#2
public void onCreated (CarGateway gateway) {
carGateway = gateway; |#3
initDisplay(); |#3
}
public void onCreateFailed (Throwable reason) {
Window.alert("Error loading data");
}
});
}
private void initDisplay () { |#4
RootPanel.get().clear();
Button button = new Button("Start your engines!");
RootPanel.get().add(button);
button.addClickHandler(new ClickHandler() {
public void onClick (ClickEvent event) {
carGateway.startEngine();
}
});
}
}
#1 Loading message
#2 Loads split point
#3 Handle loaded
#4 Initializes display

This example is our module entry point, and the first thing we do is add a loading message to the page in the form of a Label (#1). This is followed up by a call to CarGateway.createAsync() (#2), which will load the split point.

In the onCreated() method of the callback’s pass to createAsync()(#3), we can initialize the application. We do this by storing a reference to the CarGateway in the class field carGateway and then calling initDisplay().

The initDisplay() (#4) method then uses the carGateway reference to create a “Start your engines” Button and ClickHandler, which are then displayed on the page.

This example is pretty simple, but there are some things worth noting. First is that we can store a reference to the gateway class. When GWT creates a split point for the gateway it will recognize that the reference can only be null until the object is constructed. And because it is only constructed within a GWT.runAsync() call, all of the CarGateway methods can be included in the split point. To be specific, what we are trying to point out is that you can store references to the CarGateway and pass them around without breaking the split point.

Another thing to point out in this example is that, because the loading message is just a Label, it could have probably been hard-coded in the HTML page. Our example is very small, but in a larger application you might expect to find a progress bar instead of a simple text message. A progress bar is useful to the user because they can see that something is actually happening, preventing them from thinking that the application has hung.

If we had several split points, we could initiate the loading of them all at the same time and increment the progress bar as each one is completed. Then, we could use some sort of an event handler in the progress bar to initialize the application once all of the split points were loaded.

One ideal place to add a second split point in this specific application would be where we create the widgets in the initDisplay() method. If we could move this code into a gateway as well it would decrease out initial download size even further, and generally speaking the UI code is a fairly large part of more GWT applications.

When the first split point is loaded, so is the leftover code. Depending on how you have split your code, you may have a significant chunk of leftover code. To reduce the size of the leftover code GWT has one more trick up its sleeve.

Reducing leftover code by specifying load order

The leftover download shown in the Compile Report is any code that is shared across split points. If you have a lot of split points you may find that this chunk of code can be rather large. For example, if you have four split points, with 5 KB of code shared between split points A and B, and a different 5 KB of shared code used by split points C and D. If you were to load split point A, you would also be downloading the shared code for C and D, even though you might never need it.

GWT provides a mechanism to solve this problem, but, in order to do so, you need to be able to predict the load order of at least some of the split points. To do this you need to first give your split points an identity, and then reference the identity of the split point in the module configuration (listing 4).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package com.manning.gwtia.ch18.client.car;
import com.google.gwt.core.client.GWT;
import com.google.gwt.core.client.RunAsyncCallback;
public class CarGateway
{
private CarGateway () { }
public static void createAsync (final Callback callback) {
GWT.runAsync(CarGateway.class, new RunAsyncCallback() { |#A
public void onSuccess () {
CarGateway gateway = new CarGateway();
callback.onCreated(gateway);
}
public void onFailure (Throwable reason) {
callback.onCreateFailed(reason);
}
});
}
...
}
#A Identity provided

In listing 4, we omitted most of our sample so that we can focus on the GWT.runAsync() call. Here, you will see that we pass a class literal as the first argument to GWT.runAsync(). This purpose of this is only to provide a unique identity, meaning that we could have used any class literal for this purpose, but typically you would use the class literal that is related to the split point. In our case, it makes the most sense to use CarGateway.class as the identity.

The second part is to identify the order of the initial split points in the module configuration. This is done by extending the configuration property “compiler.splitpoint.initial.sequence”, as in this example:

1
2
3

<extend-configuration-property
name="compiler.splitpoint.initial.sequence"
value="com.manning.gwtia.ch18.client.car.CarGateway"/>

The value is where we specify the identity that we gave our split point. By extending this property we are signaling to the compiler that this split point will be the first to load following the initial download. Because of this the compiler can include shared code that that split point uses in this split point, increasing the size of the split point and reducing the size of the leftover code.

If you can provide the order of additional split points beyond the first, you can specify them by adding additional entries in the module configuration.

1
2
3
4
5
6

<extend-configuration-property
name="compiler.splitpoint.initial.sequence"
value="com.manning.gwtia.ch18.client.car.UIGateway"/>
<extend-configuration-property
name="compiler.splitpoint.initial.sequence"
value="com.manning.gwtia.ch18.client.car.RoadwayGateway"/>

These will again reduce the size of the leftover code, increasing the code in the split points.

The downside of specifying the load order is that if your code ends up loading a split point out of order it will need to go back and load additional split points. For example, if you declare the load order to be A B C, but, try to load C first, it will also trigger the loading of split points A and B.

So, ordering the split points can reduce your total leftover code, but requires some preplanning in order to use it effectively.

Summary

We looked at the Compile Report and code splitting. This is a fairly new tool to the GWT stack and is also one of the most anticipated. With code splitting, there is now, in theory, no upper limit on the size of your applications. With code splitting, you can break out the rarely used parts only to be loaded when they are needed. Just imagine a million-line application running in the browser, with an initial load time of less than one second. That’s amazing considering that the underlying technology, namely JavaScript, was never meant to do that.

What makes GWT such a compelling product in our minds is that it allows us to do all these things without needing to think about the underlying JavaScript all that much. That is a good thing because JavaScript implementations differ and, as a developer, you can either spend your time learning about JavaScript implementation differences, or you can spend your time coding your application. We prefer the later.

In this example, we have a html file(HttpRequest.html) with a simple button. We shall be coding for the button and the other UI elements using GWT and not HTML.When the user clicks on the button, we shall be sending a httpRequest to “Response.html”.We shall also be updating “HttpRequest.html” with the content of “Response.html” through Ajax. In this article, we shall be seeing how to do all this using GWT.

Software Requirements

• JDK 1.6
• Eclipse 3.6 IDE
• GWT SDK 1.7
• GWT Eclipse Plug-in

File Structure

Please find below the File Structure of the application. The following are the files that are to be coded:

• HttpRequest.java
• HttpRequest.html
• Response.html
• HttpRequest.gwt.xml

Let’s try to understand the File Structure. The GWT web application will have src folder which has 3 packages.

In our case, we have

• com.enr
• com.enr.client
• com.enr.server

com.enr package will have the file “HttpRequest.gwt.xml “. This is a configuration file which will be discussed more in detail later.

com.enr.client package will have the client side related files. The files that are to be converted into javascript will have to be placed here.

com.enr.server package will have the server related files, for example the servlet code etc. All the java classes that need not be converted to Java Script will have to be placed here.

An another important folder will be war which has WEB-INF folder. war folder is the one wherein all the GWT-compiler generated files will be placed.

Now let us add in code into HttpRequest.java

HttpRequest.java

This is the file, wherein, we will be coding for the front end. We shall be using GWT packages to generate UI Elements like button , label etc. The code that is present in “HttpRequest.java” will be converted to html and JavaScript by the GWT Compiler.The generated javascript code will be encapsulated into a iframe(invisible frame) and will be pasted into “HttpRequest.html”. This code will run on the browser.

Soon after the user clicks on the button, as discussed before, we need to generate a HttpRequest and also update the page with the response. Let’s try to understand how to do the same using GWT.

In order to generate a HttpRequest we need to use RequestBuilder class. RequestBuilder is a builder class which is used to generate HttpRequest Objects .This builder is however limited to build GET or POST requests.We use the method sendRequest to send the request to the specified url.In our case since we are sending the request to “Response.html”, the url should be corresponding to “Response.html”

We need to use RequestCallback class which will be invoked on recieving the response.

The RequestCallback class has two methods, onError and OnResponseRecieved which will be invoked upon getting the response depending on whether the response is positive or negative.These methods get references of the request and response objects which can be used to update the html page with the response.

In our example, we shall be sending the request on the click of the button.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

package com.enr.client;
 
	import com.google.gwt.core.client.EntryPoint;
	import com.google.gwt.core.client.GWT;
	import com.google.gwt.event.dom.client.ClickEvent;
	import com.google.gwt.event.dom.client.ClickHandler;
	import com.google.gwt.event.dom.client.KeyCodes;
	import com.google.gwt.event.dom.client.KeyUpEvent;
	import com.google.gwt.event.dom.client.KeyUpHandler;
	import com.google.gwt.http.client.Request;
	import com.google.gwt.http.client.RequestBuilder;
	import com.google.gwt.http.client.RequestCallback;
	import com.google.gwt.http.client.RequestException;
	import com.google.gwt.http.client.RequestTimeoutException;
	import com.google.gwt.user.client.Window;
	import com.google.gwt.user.client.rpc.AsyncCallback;
	import com.google.gwt.user.client.ui.Button;
	import com.google.gwt.user.client.ui.DialogBox;
	import com.google.gwt.user.client.ui.HTML;
	import com.google.gwt.user.client.ui.Label;
	import com.google.gwt.user.client.ui.RootPanel;
	import com.google.gwt.user.client.ui.TextBox;
	import com.google.gwt.user.client.ui.VerticalPanel;
	import com.google.gwt.http.client.Response;
	/**
	 * Entry point classes define onModuleLoad().
	 */
	public class HttpRequest implements EntryPoint {
 
		public static final int STATUS_CODE_OK = 200;
 
 
		public static void doGet(String url) {
			RequestBuilder builder = new RequestBuilder(RequestBuilder.GET, url);
 
			try {
				Request response = builder.sendRequest(null, new RequestCallback() {
					public void onError(Request request, Throwable exception) {
						if (exception instanceof RequestTimeoutException) {
							Window.alert("The request has timed out");
						} else {
	        			Window.alert(exception.getMessage());
						}
					}
					public void onResponseReceived(Request request, Response response) {
						if (STATUS_CODE_OK == response.getStatusCode()) {
							HTML responseLabel=new HTML("<h3>Response is gonna be updated here</H3>");
							responseLabel.setHTML(response.getText());
							responseLabel.addStyleName("response");
							RootPanel.get().add(responseLabel);
						} else {
							Window.alert(""+response.getStatusCode());
						}
					}
				});
			} catch (RequestException e) {
				// Code omitted for clarity
			}
		}
 
		public void onModuleLoad() {
			Button button=new Button("Get Response");
			button.addClickHandler(new ClickHandler(){
				@Override
				public void onClick(ClickEvent event) {
					doGet("Response.html");
				}
			});
			RootPanel.get("container").add(button);
		}	
	}

HttpRequest.gwt.xml

This is a configuration file which has information about the name of the module and entry point class and various GWT java packages that needs to be imported by the web application.

Entry point class is the class that will be executed on running the application.

1
2
3
4
5
6
7
8

<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 1.7.1//EN" "http://google-web-toolkit.googlecode.com/svn/tags/1.7.1/distro-source/core/src/gwt-module.dtd">
	<module rename-to='httprequest'>
		<inherits name='com.google.gwt.user.User'/>
		<inherits name='com.google.gwt.user.theme.standard.Standard'/>
		<inherits name="com.google.gwt.http.HTTP"/>
		<entry-point class='com.enr.client.HttpRequest'/>
	</module>

HttpRequest.html

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<html>
	<head>
		<meta http-equiv="content-type" content="text/html; charset=UTF-8">
		<link type="text/css" rel="stylesheet" href="HttpRequest.css">
		<title>Web Application Starter Project</title>
		<script type="text/javascript" language="javascript" src="httprequest/httprequest.nocache.js"></script>
		<style>
			.response
			{
				background-color: #efefef;
				padding-bottom: 1.5em; 
			}
		</style>
	</head>
	<body>
		<iframe src="javascript:''" id="__gwt_historyFrame" tabIndex='-1' style="position:absolute;width:0;height:0;border:0"></iframe>
		<h1>Getting the response through Ajax using HTTP Protocol</h1>
		<center><div id="container"></div></center>
	</body>
	</html>

Response.html

1
2
3
4
5
6
7
8

<html>
	<head>
		<title>Response</title>
	</head>
	<body>
		<h2>This is the response through GWT Http Ajax</h2>
	</body>
	</html>

Conclusion

In this article , we have seen the usage of RequestBuilder Class and RequestCallback class to send in a HttpRequest and update the page with server side response through Ajax.

• Code Splitting in GWT
• What is Model View Presenter (MVP) in GWT Application?
• History Management in GWT

GWT’s I18N support

GWT provides a module which contains all the core classes and interfaces related to internationalization in the package named com.google.gwt.i18n and the module is com.google.gwt.i18n.I18N . GWT supports two ways of internationalizing the application. They are :

• Static String Internationalization
• Dynamic String Internationalization

In this article we will discuss how to internationalize the application using Static String Internationalization. GWT provides the Static String i18n through
the interfaces like Constants, ConstantsWithLookup and Messages.

Sample Application

The sample application we discuss here demonstrates how to add I18N support to the GWT application. We will create Login application which has support for three locales English, French and Hindi. Let us see the step by step procedure for the same.

Software Requirements

Install the following softwares to run the sample application.

• JDK 1.6
• Eclipse 3.6 IDE
• GWT SDK 2.0.0
• GWT Eclipse Plug-in
• GWT plug-in for IE browser. (to run in development mode)

GWT Project Structure

How to Implement I18N in GWT?

1. Inherit the I18N module and add the locale values to the application
   module file.

• Mention each locale value that the application wants to support by extending the locale value in the Module’s XML file as shown below.

<module>

    <inherits name="com.google.gwt.user.User"/>

   <inherits name="com.google.gwt.i18n.I18N"/>

    <entry-point/>
    <extend-property name="locale" values="fr"/>
    <extend-property name="locale" values="hi"/>

    </module>

From the above configuration of the module file , it indicates that our application supports two locales French and Hindi apart from the default locale.

2. Create .properties file for each locale

• All the resource bundles must have same base name and should differ in their suffix which indicates the locale.
• The message lookup algorithm considers the base name, current locale and key of the message.
• Place all the .properties files in the src package.

AppConstants.properties is for the default locale i.e., english which has the key/value pairs as below.

username: Username
password: Password
login: Login

AppConstants_fr.properties supports French locale. The key/value pairs are as below.

username: Nom d'utilisateur
password: Mot de passe
login: connexion

3.Create an Interface corresponding to the Property Files.

• Create an interface that extends GWTs Constants interface. Resource bundles can be used by binding them to this interface.
• The base name of the property files and the interface name must be same.
• Each method in the interface corresponds to the key in the properties file.

Create the interface as shown below:

public interface AppConstants extends Constants {

String username();
String password();
String login();

}

• If the method name is different from the message key in the properties file then annotate the method with @Key annotation
  to bind the method name to message key in the resource bundle as below.

@Key(“uname”)

String username();

Where uname is the message key in the properties file.

4. Setting up the EntryPoint class.

The last step of the application is to use the Constants interface and values from the properties file.

• Create the interface object through the deferred binding mechanism that is by using GWT.create() method.
• Assign the text to the labels and buttons by using the interface methods which reads the values from the properties file.

AppConstants constants=(AppConstants)GWT.create(AppConstants.class);// Creating Interface object
	public void onModuleLoad() {
		// Getting the values from resource bundle through interface methods
		Label username=new Label(constants.username());
		Label passsword=new Label(constants.password());
		TextBox ubox=new TextBox();
		PasswordTextBox pbox=new PasswordTextBox();
		Button button = new Button(constants.login());
	}

GWT Sample Application

public class LoginI18nDemo implements EntryPoint {
	public LoginI18nDemo () {}
	AppConstants constants=(AppConstants)GWT.create(AppConstants.class);
	public void onModuleLoad() {
		Label username=new Label(constants.username());
		Label passsword=new Label(constants.password());
		TextBox ubox=new TextBox();
		PasswordTextBox pbox=new PasswordTextBox();
		Button button = new Button(constants.login());
		Grid g=new Grid(3,2);
		g.setWidget(0,0,username);
		g.setWidget(0,1,ubox);
		g.setWidget(1, 0, passsword);
		g.setWidget(1,1,pbox);
		g.setWidget(2, 1, button);
		HorizontalPanel links=new HorizontalPanel();
		Anchor french=new Anchor("French",GWT.getHostPageBaseURL()+"?locale=fr");
		Anchor hindi=new Anchor("Hindi",GWT.getHostPageBaseURL()+"?locale=hi");
		links.add(french);
		links.add(hindi);
		links.setSpacing(5);
		RootPanel.get().add(g);
		RootPanel.get().add(links);
	}
}

Conclusion

In this article we learned how to internationalize the GWT application using Static String approach, allowing the user to select the locale in which the application should be rendered. In the next article we will discuss how to Internationalize using Dynamic String approach and how to use Messages Interface.

also read:

• Code Splitting in GWT
• What is Model View Presenter (MVP) in GWT Application?
• History Management in GWT

GWT 2.0 Application Development Cookbook eases these burdens by allowing the
developers to build and maintain complex, yet highly efficient JavaScript frontend
applications in the Java programming language quickly. It tells you how to make the
web experience all the more thrilling and hassle-free by using various tools along with
the GWT SDK.

This book starts with developing an application from scratch. Right from creating the
layout of the home page to home page elements including left and right sidebars, to
placing a tree-like navigational menu, menu bars, tool bars, banners, and footers are
discussed with examples.

You will see how to create forms using the Ext GWT library widgets and handle different
types of events. Then, you will move on to see how to design a database for sales
processing systems, and learn how to create the database in MySQL with the help of
easy-to-follow recipes.

One of the interesting topics of this book is using the JPA in GWT. Using the JPA object
in GWT 2.0 is a challenge. To use it perfectly, a mechanism to convert the JPA object into a
plain object and vice versa is required. You will see recipes to use entity classes, entity
managers, and controller classes in the GWT 2.0 application. You will efficiently create
reports with parameters, variables, and subreports, and get the report output in both
HTML and PDF formats using real-world recipes.

You will then learn how to configure the GlassFish server to deploy a GWT application
with a database. Finally, you will learn how to trace speed and improve performance in
web applications using tracing techniques.

Create impressive web applications with tool bars, menus, multiple windows, and more
with this step-by-step guide.

GWT Articles & Books

• Google Web ToolKit(GWT)
• History Management in GWT
• GWT Books
• GWT Official Site

What This Book Covers

Chapter 1, Setting up the GWT Environment in NetBeans shows which tools and
technologies are required to build a web application using GWT, JPA, and iReport
in NetBeans. The required installation and configuration of the tools are shown as
easy-to-follow recipes.

Chapter 2, Creating Home Page with Panels and Menus creates the layout of the
application. It shows how to divide the page into the banner, left and right sidebars,
and the center and footer sections.

Chapter 3, Forms with Layout and Widgets includes recipes that show how to use
widgets to create forms, sidebars for navigation, tab panel, and so on.

Chapter 4, Handling your First Events includes easy-to-follow recipes that show how to
handle the typical GWT events such as button event, field event, menu event, focus
event, change event, and so on.

Chapter 5, Creating Database for Sales Processing creates a sample database in MySQL
for Sales Processing Systems. To create a database and its tables with the required
constraints, easily the uses of MySQL GUI tools have been shown.

Chapter 6, Managing Entities using JPA deals with the Java Persistence API (JPA)
framework. It is a framework that is used to manage relational data in Java EE and Java
SE applications. JPA provides a Plain Old Java Object (POJO) persistence model for
object relational mapping. This chapter shows how to create a database connection,
persistence unit, entity classes, and controller classes for the database CRUD operations.

Chapter 7, Communicating with Server using GWT RPC deals with the communication
between the client and the server. The recipes in this chapter describe how to use the JPA in
the server side and Data Transfer Objects (DTO) in the client side. It discusses how the
GWT RPC mechanism allows the server and the client to pass Java objects back and forth.

Chapter 8, Reporting with iReport shows how to use iReport for the reporting solutions
in Java web applications. Parameterized reports, subreports, and reports with variables
are shown in some recipes. Then, the chapter discusses and shows how to show the
created reports as HTML or PDF in the GWT application.

Chapter 9, Deploying a GWT Application includes recipes that show how to build the
GWT project for the deployment, and before the deployment, how to create JDBC
connection pool and resources in the GlassFish server are given as recipes.

Chapter 10, Using Speed Tracer deals with the extension Speed Tracer. Speed Tracer is a
Google Chrome browser extension which is used to identify and fix performance
problems in web applications. Installation and use of Speed Tracer for the created GWT
applications are shown in this chapter.

• Creating the home page layout class
• Adding the banner
• Adding menus
• Creating the left-hand sidebar
• Creating the right-hand sidebar
• Creating the main content panel
• Creating the footer
• Using HomePage instance in EntryPoint

Introduction

In this chapter, we will learn about creating the home page of our application. The home page
will include a banner at the top, a sidebar for navigation on the left-hand side, another sidebar
on the right-hand side for showing dynamic content, a footer to show copyright and other
information, and the main content at the center.

The layout will be as shown in the diagram below:

Creating the home page layout class

This recipe creates a panel to place the menu bar, banner, sidebars, footer, and the main
application layout. Ext GWT provides several options to define the top-level layout of the
application. We will use the BorderLayout function. We will add the actual widgets after
the layout is fully defined. The other recipes add the menu bar, banner, sidebars, and footers
each, one-by-one.

Getting ready

Open the Sales Processing System project.

How to do it…

Let’s list the steps required to complete the task.

1. Go to File | New File.
2. Select Java from Categories, and Java Class from File Types.

1. Click on Next.
2. Enter HomePage as the Class Name, and com.packtpub.client as Package.

1. Click on Finish.
2. Inherit the cla ss ContentPanel. Press Ctrl + Shift + I to import the package
   automatically. Add a default constructor:

 package com.packtpub.client;
 import com.extjs.gxt.ui.client.widget.ContentPanel;
 public class HomePage extends ContentPanel
 {
 public HomePage()
 {
 }
 }
 

Write the code of the following steps in this constructor.

1. Set the size in pixels for the content panel:

 setSize(980,630);
 

1. Hide the header:

 setHeaderVisible(false);
 

1. Create a BorderLayout instance and set it for the content panel:

 BorderLayout layout = new BorderLayout();
 setLayout(layout);
 

1. Create a BorderLayoutData instance and configure it to be used for the menu bar
   and toolba r:

 BorderLayoutData menuBarToolBarLayoutData=
 new BorderLayoutData(LayoutRegion.NORTH, 55);
 menuBarToolBarLayoutData.setMargins(new Margins(5));
 

1. Create a BorderLayoutData instance and configure it to be used for the left-hand
   sideb ar:

 BorderLayoutData leftSidebarLayoutData =
 new BorderLayoutData(LayoutRegion.WEST, 150);
 leftSidebarLayoutData.setSplit(true);
 leftSidebarLayoutData.setCollapsible(true);
 leftSidebarLayoutData.setMargins(new Margins(0, 5, 0, 5));
 

1. Create a BorderLayoutData instance and configure it to be used for the main
   contents, at the cent er:

 BorderLayoutData mainContentsLayoutData =
 new BorderLayoutData(LayoutRegion.CENTER);
 mainContentsLayoutData.setMargins(new Margins(0));
 

1. Create a BorderLayoutData instance and configure it to be used for the right-hand
   sideb ar:

 BorderLayoutData rightSidebarLayoutData =
 new BorderLayoutData(LayoutRegion.EAST, 150);
 rightSidebarLayoutData.setSplit(true);
 rightSidebarLayoutData.setCollapsible(true);
 rightSidebarLayoutData.setMargins(new Margins(0, 5, 0, 5));
 

1. Create a BorderLayoutData instance and configure it to be used for the foot er:

 BorderLayoutData footerLayoutData =
 new BorderLayoutData(LayoutRegion.SOUTH, 20);
 footerLayoutData.setMargins(new Margins(5));
 

How it works…

Let’s now learn how these steps allow us to complete the task of designing the application
for the home page layout. The full page (home page) is actually a “content panel” that covers
the entire area of the host page. The content panel is a container having top and bottom
components along with separate header, footer, and body sections. Therefore, the content
panel is a perfect building block for application-oriented user interfaces.

In this example, we will place the banner at the top of the content panel. The body section
of the content panel is further subdivided into five regions in order to place these—the menu
bar and toolbar at the top, two sidebars on each side, a footer at the bottom, and a large
area at the center to place the contents like forms, reports, and so on. A BorderLayout
instance lays out the container into five regions, namely, north, south, east, west, and center.
By using BorderLayout as the layout of the content panel, we will get five places to add
five components.

BorderLayoutData is used to specify layout parameters of each region of the container that
has BordeLayout as the layout. We have created five instances of BorderLayoutData, to
be used in the five regions of the container.

There’s more…

Now, let’s talk about some general information that is relevant to this recipe.

Setting the size of the panel

The setSize method is used to set the size for a panel. Any one of the two overloaded
setSize methods can be used. A method has two int parameters, namely, width and
height. The other one takes the same arguments as string.

Showing or hiding header in the content panel

Each content panel has built-in headers, which are visible by default. To hide the header, we
can invoke the setHeaderVisible method, giving false as the argument, as shown in the
preceding example.

BorderLayoutData

BorderLayoutData is used to set the layout parameters, such as margin, size, maximum
size, minimum size, collapsibility, fl oatability, split bar, and so on for a region in a border panel.

Consider the following line of code in the example we just saw:

 BorderLayoutData leftSidebarLayoutData =
 new BorderLayoutData(LayoutRegion.WEST, 150)
 

It creates a variable leftSidebarLayoutData, where the size is 150 pixels and the region
is the west of the border panel.

rightSidebarLayoutData.setSplit(true) sets a split bar between this region and its
neighbors. The split bar allows the user to resize the region.

leftSidebarLayoutData.setCollapsible(true) makes the component collapsible,
that is, the user will be able to collapse and expand the region.

leftSidebarLayoutData.setMargins(new Margins(0, 5, 0, 5)) sets a margin
where 0, 5, 0, and 5 are the top, right, bottom, and left margins, respectively.

Classes and packages

In the preceding example, some classes are used from Ext GWT library, as shown in
the following

See also

• The Adding the banner recipe
• The Adding menus recipe
• The Creating the left-hand sidebar recipe
• The Creating the right-hand sidebar recipe
• The Creating the main content panel recipe
• The Creating the footer recipe
• The Using the HomePage instance in EntryPoint recipe

GWT Articles & Books

• Google Web ToolKit(GWT)
• History Management in GWT
• GWT Books
• GWT Official Site

• Google Web ToolKit(GWT)
• GWT Books
• GWT Official Site

What This Book Covers

Chapter 1, Introduction, introduces the approaches and technology covered in the book,
and discusses what lies ahead.

Chapter 2, Using Eclipse and the Google Plugin, describes the basics of setting up a
project using the Eclipse IDE and Google’s GWT/GAE plugin. Topics include defining,
compiling and running an Eclipse GWT/GAE project, and using the GWT developer
browser plugin with the interactive debugger. The chapter also covers how to set up an
App Engine account and create applications, and how to deploy an app to App Engine
and access its Admin Console.

Chapter 3, Building The Connectr User Interface with GWT, focuses on GWT, and
building the first iteration of the Connectr application’s frontend. The chapter looks at
how to specify widgets, with a focus on declarative specification using GWT‘s UIBinder
and using the GWT RPC APifor server-side communication.

Chapter 4, Persisting Data: The App Engine Datastore, covers Datastore basics. In the
process, the first iteration of Connectr’s server-side functionality is built. The chapter
looks at how the Datastore works, and the implications of its design for your data models
and code development. It covers how to use Java Data Objects (JDO) as an interface to
the Datastore and how to persist and retrieve Datastore entities.

Chapter 5, JDO Object Relationships and Queries, builds on the topics of Chapter 4. It
describes how to build and manage JDO objects that have relationships to each other,
such as one-to-many and one-to-one parent-child relationships. It also covers how to
query the Datastore, and the important role that Datastore indexes play in this process.

Chapter 6, Implementing MVP, an Event Bus and Other GWT Patterns, builds on the
client-side code of Chapter 3, and shows how to make the frontend code modular and
extensible. It accomplishes this via use of the MVP (Model-View-Presenter) and Event
Bus design patterns, history/bookmark management, and an RPC abstraction, which
supports call retries and progress indicators.

Chapter 7, Background Processing and Feed Management, centers on defining and
running decoupled backend asynchronous tasks. In the process, the chapter introduces
several App Engine services, including URLFetch and Task Queues, shows the use of
Query Cursors to distribute Datastore-related processing across multiple Tasks, and
introduces the use of Java Servlets and the incorporation of third-party libraries in a
deployed application.

Chapter 8, Authentication using Twitter and Facebook OAuth and Google Accounts, adds
authentication, login, and account functionality to Connectr, allowing it to support
multiple users. The chapter demonstrates the use of both the Google Accounts APiand
the OAuth protocol for creating user accounts.

Chapter 9, Robustness and Scalability: Transactions, Memcache, and Datastore Design,
delves into more advanced Datastore-related topics. The chapter investigates Datastorerelated
means of increasing the robustness, speed, and scalability of an App Engine app,
including several ways to design data classes for scalability and to support efficient joinlike
queries. The chapter also introduces App Engine transactions and Transactional
Tasks and the use of Memcache, App Engine’s volatile-memory key-value store.

Chapter 10, Pushing fresh content to clients with the Channel API, covers the
implementation of a message push system using the App Engine Channel API, used by
Connectr to keep application data streams current. The chapter describes how to open
back-end channels connected to client-side socket listeners, and presents a strategy for
preventing the server from pushing messages to unattended web clients.

Chapter 11, Managing and Backing Up Your App Engine Application, focuses on useful
App Engine deployment strategies, and admin and tuning tools. It includes ways to
quickly upload configuration files without redeploying your entire application and
describes how to do bulk uploads and downloads of application data. The chapter also
discusses tools to analyze and tune your application’s behavior, and the App Engine
billing model.

Chapter 12, Asynchronous Processing with Cron, Task Queue, and XMPP, finishes
building the server-side part of the Connectr app. The chapter introduces the use of App
Engine Cron jobs, configuration of customized Task Queues, and App Engine’s XMPP
service and API, which supports push notifications. The chapter shows the benefits of
proactive and asynchronous updating—the behind-the scenes work that keeps Connectr’s
data stream fresh—and looks at how App Engine apps can both send and receive XMPP
messages.

Chapter 13, Conclusion, summarizes some of the approaches and technology covered in
the book, and discusses what might lie ahead.

First, in the Data modeling and scalability section we look at ways to structure and
access your data objects to make your application faster and more scalable.

Then, the Using transactions section describes the Datastore transactions, what they
do, and when and how to use them. Finally, Using Memcache will introduce App
Engine’s Memcache service, which provides a volatile-memory key-value store, and
discuss the use of Memcache to speed up your app.

In this chapter, we will use for our examples the full version of the
Connectr app, ConnectrFinal.

Data modeling and scalability

In deciding how to design your application’s data models, there are a number of
ways in which your approach can increase the app’s scalability and responsiveness.
In this section, we discuss several such approaches and how they are applied in
the Connectr app. In particular, we describe how the Datastore access latency can
sometimes be reduced; ways to split data models across entities to increase the
efficiency of data object access and use; and how property lists can be used to
support “join-like” behavior with Datastore entities.

Reducing latency—read consistency and Datastore access deadlines

By default, when an entity is updated in the Datastore, all subsequent reads of that
entity will see the update at the same time; this is called strong consistency. To
achieve it, each entity has a primary storage location, and with a strongly consistent
read, the read waits for a machine at that location to become available. Strong
consistency is the default in App Engine.

However, App Engine allows you to change this default and use eventual
consistency for a given Datastore read. With eventual consistency, the query
may access a copy of the data from a secondary location if the primary location is
temporarily unavailable. Changes to data will propagate to the secondary locations
fairly quickly, but it is possible that an “eventually consistent” read may access a
secondary location before the changes have been incorporated. However, eventually
consistent reads are faster on average, so they trade consistency for availability. In
many contexts, for example, with web apps such as Connectr that display “activity
stream” information, this is an acceptable tradeoff—completely up-to-date freshness
of information is not required.

 This touches on a complex and interesting field beyond the scope of
 this book. See http://googleappengine.blogspot.com/2010/03/
 read-consistency-deadlines-more-control.html,

http://googleappengine.blogspot.com/2009/09/migrationto-

 better-datastore.html, and http://code.google.com/
 events/io/2009/sessions/TransactionsAcrossDatacenters.
 html for more background on this and related topics.
 

In Connectr, we will add the use of eventual consistency to some of our feed object
reads; specifically, those for feed content updates. We are willing to take the small
chance that a feed object is slightly out-of-date in order to have the advantage of
quicker reads on these objects.

The following code shows how to set eventual read consistency for a query, using
server.servlets.FeedUpdateFriendServlet as an example.

 Query q = pm.newQuery("select from " + FeedInfo.class.getName() +
 "where urlstring == :keys");
 //Use eventual read consistency for this query
 q.addExtension("datanucleus.appengine.datastoreReadConsistency",
 "EVENTUAL");
 

App Engine also allows you to change the default Datastore access deadline. By
default, the Datastore will retry access automatically for up to about 30 seconds.
You can set this deadline to a smaller amount of time. It can often be appropriate to
set a shorter deadline if you are concerned with response latency, and are willing to
use a cached version of the data for which you got the timeout, or are willing to do
without it.

The following code shows how to set an access timeout interval (in milliseconds) for
a given JDO query.

 Query q = pm.newQuery("…");
 // Set a Datastore access timeout
 q.setTimeoutMillis(10000);
 

Splitting big data models into multiple entities to make access more efficient

Often, the fields in a data model can be divided into two groups: main and/or
summary information that you need often/first, and details—the data that you might
not need or tend not to need immediately. If this is the case, then it can be productive
to split the data model into multiple entities and set the details entity to be a child of
the summary entity, for instance, by using JDO owned relationships. The child field
will be fetched lazily, and so the child entity won’t be pulled in from the Datastore
unless needed.

In our app, the Friend model can be viewed like this: initially, only a certain amount
of summary information about each Friend is sent over RPC to the app’s frontend
(the Friend’s name). Only if there is a request to view details of or edit a particular
Friend, is more information needed.

So, we can make retrieval more efficient by defining a parent summary entity, and
a child details entity. We do this by keeping the “summary” information in Friend,
and placing “details” in a FriendDetails object , which is set as a child of Friend
via a JDO bidirectional, one-to-one owned relationship, as shown in Figure 1. We
store the Friend’s e-mail address and its list of associated URLs in FriendDetails.
We’ll keep the name information in Friend. That way, when we construct the initial
‘FriendSummaries’ list displayed on application load, and send it over RPC, we only
need to access the summary object.

As you may have noticed, the Friend model is already set up in this manner—this is
the rationale for that design.

Discussion

When splitting a data model like this, consider the queries your app will perform
and how the design of the data objects will support those queries. For example,
if your app often needs to query for property1 == x and property2 == y, and
especially if both individual filters can produce large result sets, you are probably
better off keeping both those properties on the same entity (for example, retaining
both fields on the “main” entity, rather than moving one to a “details” entity).

For persistent classes (that is, “data classes”) that you often access and update, it is
also worth considering whether any of its fields do not require indexes. This would
be the case if you never perform a query which includes that field. The fewer the
indexed fields of a persistent class, the quicker are the writes of objects of that cl ass.

Splitting a model by creating an “index” and a “data” entity

You can also consider splitting a model if you identify fields that you access only
when performing queries, but don’t require once you’ve actually retrieved the object.
Often, this is the case with multi-valued properties. For example, in the Connectr app,
this is the case with the friendKeys list of the server.domain.FeedIndex class (first
encountered in Chapter 7). This multi-valued property is used to find relevant feed
objects but is not used when displaying feed content information.

With App Engine, there is no way for a query to retrieve only the fields that you
need (with the exception of keys-only queries, as introduced in Chapter 5), so the
full object must always be pulled in. If the multi-valued property lists are long,
this is inefficient.

To avoid this inefficiency, we can split up such a model into two parts, and put each
one in a different entity—an index entity and a data entity. The index entity holds
only the multi-valued properties (or other data) used only for querying, and the data
entity holds the information that we actually want to use once we’ve identified the
relevant objects. The trick to this new design is that the data entity key is defined to
be the parent of the index entity key.

More specifically, when an entity is created, its key can be defined as a “child” of
another entity’s key, which becomes its parent. The child is then in the same entity
group as the parent (we discuss entity groups further in the Using transactions
section). Because such a child key is based on the path of its parent key, it is possible
to derive the parent key given only the child key, using the getParent() method of
Key, without requiring the child to be instantiated.

So with this design, we can first do a keys-only query on the index kind (which is
faster than full object retrieval) to get a list of the keys of the relevant index entities.
With that list, even though we’ve not actually retrieved the index objects themselves,
we can derive the parent data entity keys from the index entity keys. We can then do
a batch fetch with the list of relevant parent keys to grab all the data entities at once.
This lets us retrieve the information we’re interested in, without having to retrieve
the properties that we do not need.

 See Brett Slatkin's presenta tion, Building scalable, complex
 apps on App Engine (http://code.google.com/events/
 io/2009/sessions/BuildingScalableComplexApps.
 html) for more on this index/data des ign.
 

But, once we have retrieved those feeds, we don’t need the friendKeys list further.
So, we would like to avoid retrieving them along with the feed content. With our
app’s sample data, these property lists will not comprise a lot of data, but they would
be likely to do so if the app was scaled up. For example, many users might have the
same friends, or many different contacts might include the same company blog in
their associated feeds.

So, we split up the feed model into an index part and a parent data part, as shown in
Figure 2. The index class is server.domain.FeedIndex; it contains the friendKeys
list for a feed. The data part, containing the actual feed content, is server.domain.
FeedInfo. When a new FeedIndex object is created, its key will be constructed so
that its corresponding FeedInfo object ‘s key is its parent key. This construction must
of course take place at object creation, as Datastore entity keys cannot be changed.

 For a small-scale app, the payoff from this split model would
 perhaps not be worth it. But for the sake of example, let's
 assume that we expect our app to grow significantly.
 

The FeedInfo persistent class —the parent class—simply uses an app-assigned
String primary key, urlstring (the feed URL string). The server.domain.
FeedIndex constructor, shown in the code below, uses the key of its FeedInfo
parent—the URL string—to construct its key. (The Using transactions section will
describe the key-construction code of the figure in more detail). This places the two
entities into the same entity group and allows the parent FeedInfo key to be derived
from the FeedIndex entity’s key.

 @PersistenceCapable(identityType = IdentityType.APPLICATION,
 detachable="true")
 public class FeedIndex implements Serializable {
 @PrimaryKey
 @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
 private Key key;
 …

public FeedIndex(String fkey, String url) {
this.friendKeys = new HashSet<String>();
this.friendKeys.add(fkey);
KeyFactory.Builder keyBuilder =
new KeyFactory.Builder(FeedInfo.class.getSimpleName(), url);
keyBuilder.addChild(FeedIndex.class.getSimpleName(), url);
Key ckey = keyBuilder.getKey();
this.key= ckey;
}

The following code, from server.servlets.FeedUpdateFriendServlet, shows
how this model is used to efficiently retrieve the FeedInfo objects associated
with a given Friend. Given a Friend key, a query is performed for the keys of
the FeedIndex entities that contain this Friend key in their friendKeys list.
Because this is a keys-only query, it is much more efficient than returning the actual
objects. Then, each FeedIndex key is used to derive the parent (FeedInfo) key.
Using that list of parent keys, a batch fetch is performed to fetch the FeedInfo objects
associated with the given Friend. We did this without needing to actually fetch the
FeedIndex object s.

 … imports…
 @SuppressWarnings("serial")
 public class FeedUpdateFriendServlet extends HttpServlet{

private static Logger logger =
Logger.getLogger(FeedUpdateFriendServlet.class.getName());
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
PersistenceManager pm = PMF.get().getPersistenceManager();
Query q = null;
try {
String fkey = req.getParameter(“fkey”);
if (fkey != null) {
logger.info(“in FeedUpdateFriendServlet, updating feeds for:”
+fkey);
// query for matching FeedIndex keys
q = pm.newQuery(“select key from “+FeedIndex.class.getName()+”
where friendKeys == :id”);
List ids=(List)q.execute(fkey);
if (ids.size()==0) {
return;
}
// else, get the parent keys of the ids
Key k = null;
List<Key>parent list = new ArrayList<Key>();
for (Object id : ids) {
// cast to key
k = (Key)id;
parentlist.add(k.getParent());
}
// fetch the parents using the keys
Query q2 = pm.newQuery(“select from +FeedInfo.class.getName()+
“where urlstring == :keys”);
// allow eventual consistency on read
q2.addExtension(
“datanucleus.appengine.datastoreReadConsistency”,
“EVENTUAL”);
List<FeedInfo>results =
(List<FeedInfo>)q2.execute(parentlist);
if(results.iterator().hasNext()){
for(FeedInfo fi: results){
fi.updateRequestedFeed(pm);
}
}
}
}
catch (Exception e) {
logger.warning(e.getMessage());
}
finally {
if q!=null) {
q.closeAll();
}
pm.close();
}
}
}//end class

Use of property lists to support “join” behavior

Google App Engine does not support joins with the same generality as a relational
database. However, property lists along with accompanying denormalization can
often be used in GAE to support join-like functionality in a very efficient manner.

 At the time of writing, there is GAE work in progress to support simple
 joins. However, this functionality is not yet officially part of the SDK.
 

Consider the many-to-many relationship between Friend and feed information
in our application. With a relational database, we might support this relationship
by using three tables: one for Friend data, one for Feed data, and a “join table”
(sometimes called a “cross-reference table”), named, say, FeedFriend, with two
columns—one for the friend ID and one for the feed ID. The rows in the join table
would indicate which feeds were associated with which friends.

In our hypothetical relational database, a query to find the feeds associated with a
given Friend fid would look something like this:

 select feed.feedname from Feed feed, FeedFriend ff
 where ff.friendid = 'fid' and ff.feedid = feed.id
 

If we wanted to find those feeds that both Friend 1 (fid1) and Friend 2 (fid2) had
listed, the query would look something like this:

 select feed.feedname from Feed feed, FeedFriend f1, FeedFriend f2
 where f1.friendid = 'fid1' and f1.feedid = feed.id
 and f2.friendid = 'fid2' and f2.feedid = feed.id
 

With Google App Engine, to support this type of query, we can denormalize
the “join table” information and use Datastore multi-valued properties to hold
the denormalized information. (Denormalization should not be considered a
second-class citizen in GAE).

In Connectr, feed objects hold a list of the keys of the Friends that list that feed
(friendKeys), and each Friend holds a list of the feed URLs associated with it.
Chapter 7 included a figure illustrating this many-to-many relationship.

So, with the first query above, the analogous JDQL query is:

 select from FeedIndex where friendKeys == 'fid'
 

If we want to find those feeds that are listed by both Friend 1 and Friend 2, the JDQL
query is:

 select from FeedIndex where friendKeys == 'fid1' and
 friendKeys == 'fid2'
 

Our data model, and its use of multi-valued properties, has allowed these queries to
be very straightforward and efficient in GAE.

Supporting the semantics of more complex joins

The semantics of more complex join queries can sometimes be supported in GAE
with multiple synchronously-ordered multi-valued properties.

For example, suppose we decided to categorize the associated feeds of Friends by
whether they were “Technical”, “PR”, “Personal”, “Photography-related”, and so on
(and that we had some way of determining this categorization on a feed-by-feed
basis). Then, suppose we wanted to find all the Friends whose feeds include “PR”
feed(s), and to list those feed URLs for each Friend.

In a relational database, we might support this by adding a “Category” table to hold
category names and IDs, and adding a category ID column to the Feed table. Then,
the query might look like this:

 select f.lastName, feed.feedname from Friend f, Category c,
 Feed feed, FeedFriend ff
 where c.id = 'PR' and feed.cat_id = c.id and ff.feedid = feed.id
 and ff.friend.id = f.id
 

We might attempt to support this type of query in GAE by adding a
feedCategories multi-valued property list to Friend, which contained all the
categories in which their feeds fell. Every time a feed was added to the Friend, this
list would be updated with the new category as necessary. We could then perform a
JDQL query to find all such Friends:

 select from Friend where feedCategories == 'PR'
 

However, for each returned Friend we would then need to check each of their
feeds in turn to determine which feed(s) were the PR ones—requiring further
Datastore access.

To address this, we could build a Friend feedCategories multi-valued property list
whose ordering was synchronized with the urls list ordering, with the nth position
in the categories list indicating the category of the nth feed. For exam ple, suppose
that url1 and url3 are of category ‘PR’, and url2 is of category ‘Technical’. The two
lists would then be sorted as follows:

 urls = [ url1, url2, url3, … ]

feedCategories = [PR, TECHNICAL, PR, …]

(For efficiency, we would probably map the categories to integers). Then, for each
Friend returned from the previous query, we could determine which feed URLs
were the ‘PR’ ones by their position in the feed list, without requiring further
Datastore queries. In the previous example, it would be the URLs at positions 0
and 2— url1 and url3.

This technique requires more expense at write time, in exchange for more efficient
queries at read time. The approach is not always applicable—for example, it requires
a one-to-one mapping between the items in the synchronized property lists, but can
be very effective when it does apply.

GWT Articles & Books

• Google Web ToolKit(GWT)
• GWT Books
• GWT Official Site

• Code Splitting in GWT
• What is Model View Presenter (MVP) in GWT Application?
• Internationalisation(i18n) in GWT Application

Development mode 2.Production mode.

In Development Mode, the application runs java byte code within the JVM.

As it runs within the JVM it takes the advantage of java’s debugging facilities. In Production Mode ,the application run’s as JavaScript and HTML using GWT compiler which converts Java code to JavaScript.

History Class

As most other Ajax based applications, GWT applications also run in a single page. This approach of work creates the problem of Back Button. The problem is if the user needs to go to previous page or next page then the results will be unpredictable. GWT provides a solution for this problem is through the History class.

Browser history keeps track of all the URLs that are loaded. It is a dynamic stack of URLs, where the browser displays the top URL of the stack. History class is used to interact with the browser’s history stack. GWT maintains the browser history as tokens which hold the state of the application mapped to them by the developer. Token is represented as String which should be associated to a given in the program. All the History class methods are static. Some of the methods of them are getToken(), newItem(String), back(), forward() , addValueChangeHandler() and so on.

Sample Application

The sample application we discuss here demonstrates how to add history support to the GWT application. We will create Login application which has the history support. In this application, we will create two views one is Login view and the other one is Welcome view. Let us see the step by step procedure for the same.

Software Requirements

For this Sample application i have used the following software’s.

• JDK 1.6
• Eclipse 3.6 IDE
• GWT SDK 2.1.1
• GWT Eclipse Plug-in
• GWT plug-in for chrome browser. (to run in development mode)

Project Structure

Steps to add History support

1. Setup the HTML page.

• Add the following iframe to the html page(home
  page) of the application.

<iframe src="javascript:''" id="__gwt_historyFrame" tabIndex='-1'

           style="position:absolute;width:0;height:0;border:0">

          </iframe>

This iframe will be automatically inserted in the html page when creating the Application. This code is required if your application is running in ie6 or ie7 which lack the necessary onhashchange event. This script is not required for Firefox, chrome, safari or ie8 browsers. Ie8 browser supports the onhashchange event so it works on ie8 without this script.

2. Add the valueChangeHandler to the application EntryPoint Class.

The handler will be invoked on every history change event. Below is the code for adding the handler to the application.

public class LoginHistoryDemo implements EntryPoint, ValueChangeHandler {
private static final String LOGIN_TOKEN = "login";
private static final String WELCOME_TOKEN = "welcome";

Label nameError = new Label();
Label pwdError = new Label();
final TextBox nameTextbox = new TextBox();
final PasswordTextBox passwordTextbox = new PasswordTextBox();

public void onModuleLoad() {
setupHistory();
}

private void setupHistory() {
History.addValueChangeHandler(this);
History.newItem(LOGIN_TOKEN, true);
}
}

When the first time application gets loaded, there will not be any change event. We need to set the initial token for the first load using
History.newItem(LOGIN_TOKEN,true); Where in the above code LOGIN_TOKEN and WELCOME_TOKEN are two tokens representing two views of our application. The initial view of application is set to LOGIN_TOKEN.

3.Create the two views Login and welcome.

private void loadLoginView() {
    final Label loginPrompt = new Label("Please Log in");
    final Grid grid = new Grid(3, 3);
    final Label namePrompt = new Label("Name");
    final Label passwordPrompt = new Label("Password");
    final Button button = new Button("Login");
private void loadLoginView() {
final Label loginPrompt = new Label("Please Log in");
final Grid grid = new Grid(3, 3);
final Label namePrompt = new Label("Name");
final Label passwordPrompt = new Label("Password");
final Button button = new Button("Login");

button.addClickHandler(new ClickHandler() {
@Override
public void onClick(ClickEvent event) {
if (validateFormInput())
History.newItem(WELCOME_TOKEN);
}
});

loginPrompt.addStyleName("loginPrompt");
nameTextbox.addStyleName("nameField");
passwordTextbox.addStyleName("passwordField");
grid.setWidget(0, 0, namePrompt);
grid.setWidget(0, 1, nameTextbox);
grid.setWidget(0, 2, nameError);
grid.setWidget(1, 0, passwordPrompt);
grid.setWidget(1, 1, passwordTextbox);
grid.setWidget(1, 2, pwdError);
grid.setWidget(2, 1, button);

RootPanel.get().clear();
RootPanel.get().add(loginPrompt);
RootPanel.get().add(grid);
}

private void loadWelcomeView() {
final Label welcomeMsg = new Label("Welcome to the GWT History Demo");

welcomeMsg.addStyleName("welcomeMsg");

RootPanel.get().clear();
RootPanel.get().add(welcomeMsg);
RootPanel.get().add(new Hyperlink("Logout", LOGIN_TOKEN));
}

Here the username and password fields are validated using the method  validateFormInput().

protected boolean validateFormInput() {

// validating the username and password fields
String name = nameTextbox.getText();
boolean nameIsValid = name.length() > 0;
nameError.setText(nameIsValid ? "" : "Please enter the Name");

String pwd = passwordTextbox.getText();
boolean pwdIsValid = pwd.length() > 0;
pwdError.setText(pwdIsValid ? "" : "Please enter the Password");

return (name

4. Implement the onValueChangeEvent() method of the ValueChangeHandler

public void onValueChange(ValueChangeEvent event) {
     String historyToken = event.getValue();
     if (LOGIN_TOKEN.equals(historyToken)) {
        loadLoginView();
     } else if (WELCOME_TOKEN.equals(historyToken)) {
        loadWelcomeView();
     }

   }

On every History change event the appropriate view gets displayed. This changing of views should be written inside the onValueChange() method of the Handler. When the user clicks the Login button, we call History.newItem() but this time we pass the WELCOME_TOKEN token. Once again, GWT invokes our history Handler’s onValueChange method.

Putting it all Together

public class LoginHistoryDemo implements EntryPoint, ValueChangeHandler {
	private static final String LOGIN_TOKEN = "login";
	private static final String WELCOME_TOKEN = "welcome";
	Label nameError = new Label();
	Label pwdError = new Label();
	final TextBox nameTextbox = new TextBox();
	final PasswordTextBox passwordTextbox = new PasswordTextBox();

	public void onModuleLoad() {
		setupHistory();
	}

	private void setupHistory() {
		History.addValueChangeHandler(this);
		History.newItem(LOGIN_TOKEN, true);
	}

	private void loadLoginView() {
		final Label loginPrompt = new Label("Please Log in");
		final Grid grid = new Grid(3, 3);
		final Label namePrompt = new Label("Name");
		final Label passwordPrompt = new Label("Password");
		final Button button = new Button("Login");
		button.addClickHandler(new ClickHandler() {
			@Override
			public void onClick(ClickEvent event) {
				if (validateFormInput())
					History.newItem(WELCOME_TOKEN);
			}
		});
		loginPrompt.addStyleName("loginPrompt");
		nameTextbox.addStyleName("nameField");
		passwordTextbox.addStyleName("passwordField");
		grid.setWidget(0, 0, namePrompt);
		grid.setWidget(0, 1, nameTextbox);
		grid.setWidget(0, 2, nameError);
		grid.setWidget(1, 0, passwordPrompt);
		grid.setWidget(1, 1, passwordTextbox);
		grid.setWidget(1, 2, pwdError);
		grid.setWidget(2, 1, button);

		RootPanel.get().clear();
		RootPanel.get().add(loginPrompt);
		RootPanel.get().add(grid);
	}

	private void loadWelcomeView() {
		final Label welcomeMsg = new Label("Welcome to the GWT History Demo");

		welcomeMsg.addStyleName("welcomeMsg");

		RootPanel.get().clear();
		RootPanel.get().add(welcomeMsg);
		RootPanel.get().add(new Hyperlink("Logout", LOGIN_TOKEN));
	}

	protected boolean validateFormInput() {

		// validating the password is not empty
		String name = nameTextbox.getText();
		boolean nameIsValid = name.length() > 0;
		nameError.setText(nameIsValid ? "" : "Please enter the Name");

		String pwd = passwordTextbox.getText();
		boolean pwdIsValid = pwd.length() > 0;
		pwdError.setText(pwdIsValid ? "" : "Please enter the Password");

		return (nameIsValid && pwdIsValid);
	}

	@Override
	public void onValueChange(ValueChangeEvent event) {
		String historyToken = event.getValue();
		if (LOGIN_TOKEN.equals(historyToken)) {
			loadLoginView();
		} else if (WELCOME_TOKEN.equals(historyToken)) {
			loadWelcomeView();
		}

	}

}

Conclusion

also read:

• Code Splitting in GWT
• What is Model View Presenter (MVP) in GWT Application?
• Internationalisation(i18n) in GWT Application

In this article we learned how to add History support to the GWT application, allowing the user to use the Back and Forward buttons of the browser at will, leading to a general launcher for any application.

This book gets you up and running instantly to build powerful Rich Internet Applications
(RIA) with Ext GWT. It then takes you through all the interface-building widgets and
components of Ext GWT using practical examples to demonstrate when, where, and how
to use each of them. Layouts, forms, panels, grids, trees, toolbars, menus, and many other
components are covered in the many examples packed in this book. You will also learn to
present your data in a better way with templates and use some of the most sought-after
features of Ext GWT in your web applications such as drag-and-drop and charts.
Throughout the book, a real application is built step-by-step using Ext GWT and
deployed to Google App Engine.

Imagine how great you’ll feel when you’re able to create great-looking desktop-style user
interfaces for your web applications with Ext GWT!

GWT Articles

• Buy GWT in Action from GWT Books Store
• Comparison of AJAX Frameworks
• Google Web ToolKit(GWT)

What This Book Covers

Chapter 1, Getting Started with Ext GWT, introduces Ext GWT and explains where it fits
into GWT. It then moves on to show how to get up and running with Ext GWT by
creating your first project.

Chapter 2, The Building Blocks, starts by looking at the explorer demo application. It
then introduces the world of GXT components, beginning with some key concepts, and
quickly moves on to practically working with an example application.

Chapter 3, Forms and Windows, explores GXT’s form features. It looks at the form
components that GXT provides and demonstrates how to put them to use. It also
introduces the GXT Registry and shows how it can be used across the application.

Chapter 4, Data-backed Components, explains how GXT facilitates working with data. It
looks at the components available for retrieving, manipulating, and processing data and
then moves on to work with the built-in data-backed display components.

Chapter 5, More Components, introduces more advanced data-backed components
and the extensions that build on the components covered in the previous chapter. It
then moves on to cover additional advanced components—specifically menus, toolbars,
and tabs.

Chapter 6, Templates, looks at templates and how they can be used to easily format and
display data in a highly customizable way. It also introduces the more powerful features
of XTemplates.

Chapter 7, Model View Controller, explains GXT’s Model View Controller framework
and demonstrates how it can allow components to communicate in larger applications.

Chapter 8, Portal and Drag-and-Drop, covers the portal and drag-and-drop features
of GXT. It starts by showing how to turn out existing components into portlets and
then moves on to practically make use of GXT’s drag-and-drop features to move data
between them.

Chapter 9, Charts, covers GXT’s charting plugin. It explores the wide range of charts
available, shows how to avoid the pitfalls of the plugin, and demonstrates how charts can
be used with existing data.

Chapter 10, Putting it all together, shows how to publish the example application to the
world using the Google App Engine. It then moves on to look at how to take
development with GXT further and other resources that can be turned to after this book.

 In this chapter, we introduce how GXT allows us to work with data. We look at
 the components available for retrieving, manipulating, and processing data,
 and then move on to work with the built-in data-backed display components.
 

We shall cover the following components:

Data

• ModelData
• BeanModel
• BeanModelTag
• BeanModelMarker
• BeanModelFactory
• Stores

Remote Data

• DataProxies
• DataReaders
• ListLoadResults
• ModelType
• Loaders
• LoadConfigs

Data-backed components

• ListField
• ComboBox
• Grid
• ColumnModel
• ColumnConfig
• GridCellRenderer

Working with data

One of the advantages of AJAX applications, including those built with GXT, is the ability to
manipulate data in the browser. GXT provides useful data-backed visual components that
allow us to work with local data such as lists, combos, and grids. With them we can perform
sorting, filtering, and editing operations on data quickly and efficiently.

There is also another set of components that work in the background allowing us to retrieve
remote data, cache it on the client, and deliver it to the visual components. It is these two
sets of components that we are going to focus on in this chapter.

First of all, we are going to look at how to produce the data that we need for display in the
visual components.

ModelData interface

GXT provides us an interface named ModelData. Any data objects we wish to use with GXT
data-backed components must implement this interface. The ModelData interface provides
the ability for property names and values to be retrieved at runtime. As GWT does not
support refl ection, GXT does this using a form of introspection.

In our example application, at present we are using a JavaBean named Feed to store feed
data. However, at the moment, it does not implement the ModelData interface, so we
cannot use it with GXT’s data-backed components.

We have three methods that will allow us to achieve this:

1. Modify the Feed JavaBean so that it extends BaseModel.
2. Modify the Feed JavaBean so that it implements BeanModelTag.
3. Create a BeanModelMarker interface to accompany the Feed JavaBean.
   This method allows us to avoid having to modify the Feed JavaBean.

Method 1: Extending BaseModel

BaseModel is the default implementation of the ModelData interface. Classes that extend
BaseModel make use of a HashMap to store data rather than local fields. Data is added and
retrieved using the set and get methods of the BaseModel respectively. The downside
of this method is that we need to use strings as attribute names and as such it is easier for
errors to creep in.

The Feed object implemented as a subclass of BaseModel would look like this:

 public class Feed extends BaseModel {
 public Feed () {
 }
 public Feed (String uuid) {
 set("uuid", uuid);
 }
 public String getDescription() {
 return get("description");
 }
 public String getLink() {
 return get("link");
 }
 public String getTitle() {
 return get("title");
 }
 public String getUuid() {
 return get("uuid");
 }
 public void setDescription(String description) {
 set("description", description);
 }
 public void setLink(String link) {
 set("link", link);
 }
 public void setTitle(String title) {
 set("title", title);
 }
 }
 

BeanModel class

If we already have a JavaBean we wish to use instead of creating a new BaseModel, GXT
provides the BeanModel, a class which acts as a wrapper for JavaBeans. BeanModel objects
cannot be created directly; instead they are generated by a BeanModelFactory.

BeanModelFactory class

BeanModelFactory is a useful class that allows us to take a JavaBean with a
corresponding BeanModelMarker interface such as a Feed object, and get back
a BeanModel representation.

The remaining two methods of providing a ModelData object involve wrapping a JavaBean
as a BeanModel.

Method 2: Implementing BeanModelTag

BeanModelTag is an interface that allows us to tag existing Java objects that meet the
JavaBean specification. This allows BeanModel instances to be generated from the JavaBean
using a BeanModelFactory.

In order to make our existing Feed JavaBean usable as a GXT BeanModel, we simply need to
implement the BeanModelTag interface like this:

 public class Feed implements Serializable, BeanModelTag {
 private String description;
 private String link;
 private String title;
 private String uuid;
 public Feed() {
 }
 public Feed(String uuid) {
 this.uuid = uuid;
 }
 public String getDescription() {
 return description;
 }
 public String getLink() {
 return link;
 }
 public String getTitle() {
 return title;
 }
 public String getUuid() {
 return uuid;
 }
 public void setDescription(String description) {
 this.description = description;
 }
 public void setLink(String link) {
 this.link = link;
 }
 public void setTitle(String title) {
 this.title = title;
 }
 }
 

This still requires a change to the JavaBean, however. There are situations where making
any change to a JavaBean would be unacceptable or at least undesirable. In this case, GXT
provides the BeanModelMarker.

Method 3: Creating a BeanModelMarker

BeanModelMarker is an interface, which, as its name suggests, allows us to mark an
existing JavaBean as a BeanModel. This is achieved by creating an interface that extends
BeanModelMarker. It makes use of annotations to define the JavaBean to wrap.

In our example application, we already have a Feed JavaBean, and we will now create a
BeanModelMarker for it so that we can use it with the GXT data-backed controls.

Notice the use of the @BEAN annotation to make a reference to the Feed class. We do not
need to make any changes to the Feed JavaBean itself.

Time for action – creating a BeanModelMarker for Feed objects

1. Create a new class named FeedBeanModel that implements the
   BeanModelMarker interface in a new package named client.model:

   public class FeedBeanModel implements BeanModelMarker {}

2. Add an @BEAN annotation to tell GXT to use the Feed JavaBean class as follows:

 @BEAN(com.danielvaughan.rssreader.shared.model.Feed.class)
 public class FeedBeanModel implements BeanModelMarker {}
 

What just happened?

We created a BeanModelMarker for our existing Feed JavaBean. We can now use our Feed
JavaBean with GXT’s data-backed controls without having to modify the Feed JavaBean class
in any way.

Stores

In GXT, a Store is an abstract class used to provide a client-side cache of ModelData objects
of a specified class. Stores are where the data-backed GXT components keep data. There are
two concrete Store classes. The first is TreeStore, which is used with Tree components,
and we will look at these in the next chapter. The second is ListStore, which is used for
storing the lists of data. These are typically used with ListField, ComboBox, and
Grid components.

To create a ListStore to contain Feed objects, we would define it like this:

 ListStore<BeanModel> feedStore = new ListStore<BeanModel>();
 

Note that the ListStore is set to contain BeanModel instances. This is because a Store
can only contain objects that inherit from the ModelData class. If we wanted to add a Feed
JavaBean object, we cannot do it directly. We need to use a BeanModelFactory to convert
the Feed JavaBean object into a BeanModel representation.

We will now modify the example application so that when creating a new Feed
JavaBean object, a BeanModel representation of the Feed object is added into
a client-side ListStore.

Time for action – creating and populating a ListStore

1. In the RSSReaderConstants class, add a new constant named FEED_STORE for
   the feed store:

 public static final String FEED_STORE = "feedStore";
 

1. In the onModuleLoad method of the RSSReader class, create a new ListStore
   and add it to the Registry using the FEED_STORE constant as the key:

 public void onModuleLoad() {
 Registry.register(RSSReaderConstants.FEED_SERVICE,
 GWT.create(FeedService.class));
 Registry.register(RSSReaderConstants.FEED_STORE, new
 ListStore<BeanModel>());
 …
 }
 

1. In the save method of the FeedForm, modify the onSuccess method of the
   callback function to retrieve the feed store from the Registry:

 public void save(final Feed feed) {
 @Override
 public void onSuccess(Void result) {
 Info.display("RSS Reader", "Feed " + feed.getTitle()
 + " saved successfully");
 final ListStore<BeanModel> feedStore = Registry
 .get(RSSReaderConstants.FEED_STORE);
 }
 …
 }
 

1. Retrieve a BeanModelFactory for the Feed class:

 public void onSuccess(Void result) {
 Info.display("RSS Reader", "Feed " + feed.getTitle() + " saved
 successfully");
 final ListStore<BeanModel> feedStore =
 Registry.get(RSSReaderConstants.FEED_STORE);
 BeanModelFactory beanModelFactory =
 BeanModelLookup.get().getFactory(feed.getClass());
 }
 

1. Finally, use the BeanModelFactory to create a BeanModel representation of the
   Feed object and then add it to the feed store:

 public void onSuccess(Void result) {
 Info.display("RSS Reader", "Feed " + feed.getTitle() + " saved
 successfully");
 final ListStore<BeanModel> feedStore =
 Registry.get(RSSReaderConstants.FEED_STORE);
 BeanModelFactory beanModelFactory =
 BeanModelLookup.get().getFactory(feed.getClass());
 feedStore.add(beanModelFactory.createModel(feed));
 }
 

What just happened?

Feed objects are now stored in a GXT ListStore. The advantage of this is that we can now
simply link the data-backed components to the Store, and the values in the components
will refresh automatically.

Data-backed ComboBox

Once we have a ListStore populated with data, we can use it to provide the options in a
ComboBox by binding the ComboBox to the Store. We would take the feed store and create
a ComboBox that uses the title field of each Feed to populate the values of the ComboBox
like this:

 ComboBox<Feed>combo = new ComboBox<Feed>();
 combo.setDisplayField("title");
 combo.setStore(feeds);
 

Here we use the setDisplayField of the ComboBox to set the title field as the field to use
as the display value.

Once a data-backed component is linked with a Store, it then observes the Store for
changes. If a change to the data in the Store occurs, such as an object being added to the
Store, the content of the data-backed control will be updated automatically. The specific
Store events that can be observed are listed as follows:

• Add
• Clear
• Data Changed
• Filter
• Remove
• Sort
• Update

Data-backed ListField

Associating a ListField with a Store is very similar to associating a ComboBox with a
Store. In our example application, we will now add a ListField containing all current
feeds to the left navigation panel.

Time for action – creating a ListField for feeds

1. Create a new package named client.lists, and in it create a new class named
   FeedList that extends LayoutContainer:

 public class FeedList extends LayoutContainer {}
 

1. In the constructor of the FeedList class, set the layout of the LayoutContainer
   to FitLayout:

 public FeedList() {
 setLayout(new FitLayout());
 }
 

1. Override the onRender method, and in it create a new ListField:

 @Override
 protected void onRender(Element parent, int index) {
 super.onRender(parent, index);
 final ListField<BeanModel> feedList = new
 ListField<BeanModel>();
 }
 

1. Again in the onRender method, retrieve the feed store from the Registry:

 final ListStore<BeanModel> feedStore =
 Registry.get(RSSReaderConstants.FEED_STORE);
 

1. Set the feed store as the Store for the feed list ListField:

 feedList.setStore(feedStore);
 

1. Tell the ListField to use the title field of the Feed object as the value to display in
   the ListField:

 feedList.setDisplayField("title");
 

1. Add the ListField to the underlying container:

 add(feedList);
 

1. At the end of the constructor of the RssNavigationPanel, set the layout to a new
   instance of FitLayout and add a new instance of the FeedList component to
   the underlying ContentPanel:

 setLayout(new FitLayout());
 add(new FeedList());
 

1. Start the application, click on the Create feed button, and complete the form as
   shown in the screenshot below:

1. On clicking the Save button, the new feed’s title, Test Feed, will appear in the list
   of feeds on the left:

What just happened?

We added a list of feeds to the RSS Reader application. When we created a new feed, it
automatically appeared in the feed list on the left.

GWT Articles

• Buy GWT in Action from GWT Books Store
• Comparison of AJAX Frameworks
• Google Web ToolKit(GWT)

1
2
3
4
5
6
7
8
9
10

<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <title>Simple GWT Host Page</title>
    <script type="text/javascript" language="javascript" src="com.google.gwt.sample.tempraturewatch.TempratureWatch.nocache.js"></script>
  </head>
  <body>
    <div id="tempratureWatchDiv"></div>
  </body>
</html>

In the above host page we can see that the GWT application is included through the script tag. The nocache.js is an auto generated file created using the applicationcreator command (Refer : GWT installation and creating a GWT Project for information on the applicationcreator). Next, we can see a div tag with the id attribute.
In GWT we can insert content into selective sections of the HTML page. Lets look at an example :

1
2

final Button button = new Button("Submit");
RootPanel.get("tempratureWatchDiv").add(button);

In the above code snippet, we can see that usage of the class RootPanel. The RootPanel is the container for all other GWT components. We use the RootPanel class to get a reference of tempratureWatchDiv division. Once we have a reference to it we can add Widgets(controls) to the html page.

Widgets

Widgets are controls which allow the users to interact with the system. Lets look at the different types of widgets available in GWT:

• Button

– Button enables the user to take a certain action

• TextBox

– Textbox allows the user to enter data as text

• Tree

– Tree represents a hierarchy of other widgets

• RichTextArea

– RichTextArea provides the user to perform editing features on text

• Checkbox

– Checkbox allows multiple selection of items

• RadioButton

– RadioButton allows only single selection of items

• PasswordTextBox

– PasswordTextBox is used to input password. The typed characters are not displayed as it is.

• TextArea

– TextArea allows the user to enter text over multiple lines

• Hyperlink

– Hyperlink allows you to link to an URL

• Listbox

– Listbox allows multiple selection from a list of items

• MenuBar

– MenuBar allows you to implement a standard menu bar. Menu bar can hold one or more menus.

• SuggestBox

– SuggestBox is like a textbox but it provides suggestions based on the user input. The suggestions provided are pre-configured.

• Table

– Table control mimics the HTML table

• Dialog Box

– Dialog Box represents a form of popup

In addition to these we can also create custom widgets.

Panels

Panels are used as container for widgets and subpanels. Panels also define how the widgets will be laid out. Lets look at the type of panels in GWT:

• Dock Panel

– Using dock panels the widgets are aligned directionally

• Horizontal Panel

– Provides horizontal alignment of controls

• Tab Panel

– Provides tabular arrangement of controls

• Root Panel

– The Root panel holds the reference to the entire GWT interface.

• Stack Panel

– The stack panel displays the components vertically by stacking its children.

• Popup Panel

– The popup panel is a popup which can popup up over other widgets

• Vertical Panel

– The vertical panel lays out the components in a vertical column

• Flow Panel

– This panel lays out it components in the same manner as the default HTML layout

• Vertical Split Panel

– This panels splits the window verticals into two widgets

• Horizontal Split Panel

– This panels splits the window horizontally into two widgets

Style Sheets

In GWT we can apply style information to content by using Cascading Style Sheets (CSS). This is very similar to the way we apply style information to HTML pages. Each widget class in GWT has a addStyleName method which takes a string parameter. The string parameter associates a style name with the widget. The same name should be defined in the CSS file. Under the name we can set visual styling information. The reference to the CSS should be made in the GWT module. Let us now look at how we can make use of style sheets in a GWT application.

As a first step we have to associate the style attribute in the Java class:

1
2

Label nameLabel = new Label();
nameLabel.addStyleName("LabelStyle");

The next step would be to define the style attribute in the CSS file:

1
2
3
4

.LabelStyle {
  color: blue;
  font-size: large;
}

The final step would be to declare the style sheet file in the XML module. This enables the GWT to know exactly where to look for the styling information.

1
2
3
4
5

<module>
	<!--Other application level settings-->
	.......
	<stylesheet src='MyStyleSheet.css' />
</module>

GWT Reference

• GWT installation and creating a GWT Project
• GWT Articles