Sunday, June 20, 2010

More Complex GWT Events

We have already created a small application where we can successfully add a new contact. Now it is time to create the necessary plumbing to edit a contact. To make this work, we need to create an event handler that actually passes the contact (or its reference) along with it, so that whoever picks up the event can read out which contact needs to be edited.

We will first create the EditContactEvent class and the EditContactEventHanlder interface. After that, we shall reuse the contact popup to allow the user to edit the clicked contact on the contact list.

Tuesday, June 8, 2010

The GWT Handlers, Events, and the Event Bus

We have setup our MVP framework, and made our first GWT-RPC service call. Now it is time to create some event wiring. After all, those buttons we painted on the ContactsView should actually do something. So how is this done?

It is very simple. The first thing you do is to add a handler to a particular widget. For example, you would add a ClickHandler to a Button. By adding this handler, you can choose to fire an event. You fire events in the eventBus (which is an instance of the HandlerManager we created in the EntryPoint).

Next, you can then add handlers to the eventBus that will listen for that specific event you fired, and perform whatever task you like.

In our MVP framework, all the wiring of handlers and events is done in the presenters. So the binding of the ClickHandler goes there, the firing of the event in the eventBus goes there, as well as the binding of the handler on the eventBus to pick up that fired event goes there (but most likely in a different presenter - more on that later).

Monday, June 7, 2010

The GWT RPC Service

In my previous post we created the initial MVP framework with a simple view to display our mock contacts. In this post we will add the RPC Service call to extract the mock contacts from our mock DAO, and list them on the screen.

The code to collect the contacts from our rpcService and displaying them on our ContactsView should be handled by the ContactsPresenter. After all, in the MVP framework, all logic to manipulate and present data should be in our presenters, never in our views.

You may also remember that doing RPC calls is expensive, and that you want to minimize the amount of data that gets transferred between server and client. That was why we created two types of contacts: Contact and ContactLight. Where the Contact class contains all our contact's data, the ContactLight class only contains an id and a display name. This is exactly all we need for showing the contacts in a list.

Friday, June 4, 2010

Creating The MVP Framework

Our first step was to clean the starter application from unwanted code, and flesh out the contacts service. We created mock contacts and a contacts service implementation making use of GWT-RPC. Now it is time to create our Model-View-Presenter (MVP) framework.

As you may have guessed, the MVP framework consists of code that goes in the Model, code that goes in the View, and code that goes in the Presenter. What we created last time was basically the Model part (Contact, ContactLight, ContactService, etc).

Thursday, June 3, 2010

Stubbing Out The Contacts Sample Application

So we generated the starter GWT and AppEngine application. Now it is time to clean this one up so we are only left with stuff that we need. We will start first with deleting some project starter classes which we do not need, and then we will edit some of the classes and html files that we will keep.

Wednesday, June 2, 2010

The GWT & AppEngine Starter Project

First step is for us to create a new Google AppEngine For Java (or gaej for short) project. We will use the Eclipse IDE and the Google Plugin. Be sure to have those installed first. In this sample I have used the Google Plugin for Eclipse 3.5 (v1.3.2) and the Google Web Toolkit SDK (v2.0.3).

GWT and MVP

A while back I had to come to grips with GWT for work. After doing a few tutorials, I quickly realized that things can become very complicated if you do not apply a good design pattern. For GUI frameworks, Martin Fowler suggests the MVP design pattern is a good bet, and it seems the guys at Google think so too.

After reading up on their documentation, and downloading the sample app that came with it, I still did not get very far. It skims over certain areas since it was written for people more knowledgeable than me, and it lacked some features I liked to explore too, like app engine and use of Guice/Gin.

Luckily, there is plenty of information found on the net about GWT, AppEngine, and Guice. All that I need to do is put it all together to create a sample app and documentation that makes sense to me.