Chris’ Musings

Now that I have upgraded to 1.6, I’m looking at the new Event system.  Moving from the “Listener”‘ model to the “Event” model is pretty straight forward.  You can read all of the benefits of the new Event code on the GWT site.  For me, the best benefit is that I can use the new architecture to replace a home grown event bus.  Our existing infrastructure is very similar but not quite as robust.  The GWT docs are a good starting point and will walk you through how to use the new Event Handler methods with existing widgets.  Upgrading is a fairly painless change – just takes time to update everywhere.

The real payoff for me came when I added events.  This takes a little more work; but seems to be worth it.  The primary advantages for my framework are:

• lower direct coupling between components
• a given component can register for multiple different events (I was using a large switch statement after evaulating the “type” of event under the old architecture)

To use create a new Event, the following needs to be created.  I combined the Event and Handler into 1 class:

import com.google.gwt.event.shared.EventHandler;
import com.google.gwt.event.shared.GwtEvent;
 
public class MyEvent extends GwtEvent<MyEvent.IMyHandler>{
 
   //marker for handler logic in registration method
   public interface IMyHandler extends EventHandler{
      void onLoad(MyEvent event);
   }
 
   //marker on calling
   public interface ITakesMyEvent extends EventHandler{
      void process(MyEvent event);
   }
 
   private static final GwtEvent.Type<MyEvent.IMyHandler> TYPE = new GwtEvent.Type<IMyHandler>();
 
   public static GwtEvent.Type<IMyHandler> getType(){
      return TYPE;
   }
 
   @Override
   protected void dispatch(MyEvent.IMyHandler handler){
      handler.onLoad(this);
   }
 
   @Override
   public GwtEvent.Type<IMyHandler> getAssociatedType(){
      return TYPE;
   }
}

On your component you need to add a couple of methods:

import com.google.gwt.event.shared.EventHandler;
import com.google.gwt.event.shared.GwtEvent;
import com.google.gwt.event.shared.HandlerManager;
import com.google.gwt.event.shared.HandlerRegistration;
 
public class MyComponent {
 
   private HandlerManager handlerManager;
 
   /**
    * Adds this handler to the widget.
    *
    * @param  the type of handler to add
    * @param type the event type
    * @param handler the handler
    * @return {@link HandlerRegistration} used to remove the handler
    */
   //copied from GWT 1.6 Widget
   protected final <H extends EventHandler> HandlerRegistration addHandler(GwtEvent.Type<H> type, final H handler){
      return ensureHandlers().addHandler(type, handler);
   }
 
   /**
    * Ensures the existence of the handler manager.
    *
    * @return the handler manager
    * */
   //copied from GWT 1.6 Widget
   private HandlerManager ensureHandlers(){
      return handlerManager == null ? handlerManager = new HandlerManager(this) : handlerManager;
   }
 
   /**
    * Register a component for the specified event.
    */
   public void register(final MyEvent.ITakesMyEvent component){
      addHandler(MyEvent.getType(), new MyEvent.IMyHandler(){
         public void onLoad(MyEvent event){
            component.process(event);
         }
      });
   }
 
   /**
    * Fire an event.
    */
   void fireEvent(GwtEvent<?> event){
      handlerManager.fireEvent(event);
   }
}

In your component you then fire the event handler:

public void doSomething(){
   System.out.println("Doing Something");
   fireEvent(new MyEvent());
}

Your “listening” component would have look like:

public class TestComponent implements MyEvent.ITakesMyEvent {
   public TestComponent{
      MyComponent component = new MyComponent();
      component.register((MyEvent.ITakesMyEvent)this);
   }
 
   public void process(MyEvent event){
      //do something with event
   }
}

With GWT 1.6, we now have the ability to add very fine grained event processing to our components.

My next step is to look into the memory handling aspect to make sure all of the “Event” objects are removed from memory when the declaring object (TestComponent above) is removed.  I’m fairly confident this is the case.  I just noticed some “removal” code in the PopupPanel class that I need to investigate further.

So I am upgrading our application framework to GWT 1.6 (from 1.5). The next several posts will be about the little things I learned and don’t want to forget. The initial upgrade process was pretty painless.  The source itself went relatively smoothly.  The build process was another issue.  The most challenging portion was the RPC calls.

With 1.6, the packaging structure moved to a war hierarchy.  The war directories are used by hosted mode.  The modules are compiled into a subdirectory of the war based on the module “rename-to” attribute.  This attribute becomes part of the GWT.getModuleBaseURL() which is what we use to prepend all of our service calls:

private LoginServiceProxy() {
   proxy = (RoutingServiceAsync)GWT.create(LoginService.class);
   ServiceDefTarget endpoint = (ServiceDefTarget)proxy;
   endpoint.setServiceEntryPoint(GWT.getModuleBaseURL() + "login");
}

The getModuleBaseURL() now includes the “rename-to” parameter.  This was causing some grief until I remembered that.  I now need to build the endpoint URL without the module name.   This will allow me to remove the apache rewrites and/or allow for the applications to run in both hosted and webmode.  Don’t ask, I did some creative stuff to get our RPC calls to work until I remembered this code.

If you haven’t had fun with timezones before, you haven’t developed enough software

For several of our applications we had a timezone consistency problem.  There is lots of information on the net about Timezones and Java – don’t forget your operating system and physical BIOS time settings.  Our production machines are set to EST5EDT (Eastern Standard Time – No Day Light Savings).

To set the applications to use this timezone, java needs to be told.  The easiest way is to add a parameter to the startup script

java -Duser.timezone=EST5EDT ....

Now all of our components agree (OS / BIOS / Java) that the timezone is EST5EDT or  GMT-5.

Next up will be setting all of the servers to GMT (which we should have done from the start years ago).  All of the applications should store dates in GMT and only translate into the correct format based on the users preferences.  For most of our applications (which are multi-tenant) we are going to set the timezone at the tenant level.  So if you want your times to be in EST, then they can be.  If another tenant wants their time in PST, that will work also.

We have a lot of the plumbing in place to do this.  The only piece left to work on is reporting.  Since reports are generated directly against the DB, a method needs to be determined to convert them to the tenants prefered TZ.

For one of my clients I have written a wordpress plugin that can sit in the widget sidebar.  It allows a viewer of their blog to register to an email list in the Eureka! application.  The email list to subscribe to is set on a global basis for the entire blog.

I had a feature request that the email list should depend on the post/page being viewed.  It turns out this is simple – but really hard to figure out. There is a lot of documentation on wordpress, just some of the probably basics are not readily apparent.

So I opened google and started digging.  Turns out, there must not be a lot of demand for knowing which post/page someone is viewing in a widget plugin.  After a couple of hours of digging I finally figured out:

1. I can access a global wordpress object that will contain lots of good information
2. Custom fields can be assigned to a post/page

The relevant snippet of code is:

1
2
3

global $wp_query;
$postid = $wp_query->post->ID;
$customFieldValue = get_post_meta($postid, 'customFieldKey', true);

And volia, I now have the custom field value based on the post/page someone is viewing.

I have been meaning to start writing down some thoughts for a while. Since I have had to delve into WordPress for one of my clients and write some widgets (more on that later), I have decided to start!

About me real quick, I graduate from Indiana University in 1994 with a double major in Finanace and Computer Information Systems and a minor in Economics. I almost had my minor in Computer Science but decided I didn’t want to take the required Assembly Language classes – as far as exciting cs courses go I had my fill with cobol. I went to work for Deloitte & Touche Consulting (they are now just Deloitte) after graduation in their System Implementation Group.

I worked for Deloitte for 8 years working my way through the ranks to where I was managing large system implementations. I loved the work and the people; but 100% travel and a social life do not co-exist very nicely. So I started doing my own thing. I started off with a small project building a web application using Struts and built my way up to managing the development of large web applications. In that time I also got married and now have two children.

I have spent the last 8 years building web applications. First with struts, then JSF/Seam and now I am working with GWT (Google Web Toolkit). I have had a lot of fun building applications and this is what I will be blogging about. As I learn new things, I want a place to write down what I learned so I can refer to my notes later.

If you are reading this, Great! I hope my journey can help you.

Chris….