Monday, September 21, 2009

Building Opera Unite Services in Java

For the last few weeks I've been experimenting with Opera Unite, due to be release in the next version of the Opera browser. Opera Unite services are built in JavaScript, however this felt like a limitation as building anything big in JavaScript alone can get a little hairy.

With this in mind I started on a few experiments to see if I could use GWT as a framework to build these services, thus allowing me to stay directly in the nice type safe world of Java.

GWT-Unite is the result of these experiments. It's a set of API's that allow easy creation of Opera Unite services without ever seeing a scrap of JavaScript! If your interested in taking a look, I've hosted it over at Google Code (gwt-unite.googlecode.com) where you'll find the source code, libaries, examples and documentation. If you have any ideas on how to make it better, why not join me!

Saturday, July 04, 2009

GWT Logging and JSNI

Logging is an essential component of any traditional Java environment, without it, tracking down issues would be time consuming. Unfortunately, on the browser, there's no standard place in which to output log messages. Sure, one solution could be to display a dialog box when something goes wrong, but normally you want to dsplay such things as debug messages which just won't work in a dialog solution.

As a solution to this most browsers provide some kind of logging console exposed through a JavaScript API. One of the best known, and possibly most widely used, is Firebug a JavaScript debug enviroment plugin for Firefox; others includeDragonFly for Opera and the new debug console for Internet Explorer 8. Whilst all these facilities are fantastic for direct JavaScript development, how do we access them from a GWT application?

Here I introduce my simple but effective GWT Logging Module that automatically detects the available browser logging system and connects to it. It was developed as a way of demonstrating GWT JSNI usage but developed into a framework which I use today.

If your too impatient are simply don't want to learn about JSNI, the full Logging module is available ready to use here and if your interested in the source, it's available as an Eclipse project here.

Using The Framework

Firstly the logging module needs to be added to your Eclipse build path, and then the following to your GWT module descriptor :

<inherits name="com.maddison.gwt.logging.Logging"/>

This single line will instantiate the Logging system when the application starts at which point you will see a "Logger Started" message displayed on whichever logging system your browser has installed. To access the Logger from your application simple use the following line :

private static final Logger LOG = Logging.getLogger();

All the logging methods of Logger are now available, for example :

private static final Logger LOG = Logging.getLogger();

public void doSomething() {
 LOG.info("Hello World");
}

The following logging systems are supported:

  • Opera -> DragonFly
  • Firefox -> Firebug
  • GWT hosted mode -> GWT console
  • IE8 -> Debug console
  • Chrome -> JavaScript console

Filtering Logging

A minimum logging level can be specified either as a URL parameter or as a meta tag parameter. The following shows example these:

....index.html?minLogLevel=WARN

or

<head>
 <meta name="minLogLevel" value="WARN"/>
</head>

In both the above examples only warning or higher severity messages will be logged. The severity level's are (most severe first) NONE, ERROR, WARN, INFO, DEBUG, ALL.

How It works

As mentioned in the introduction, this logging system was developed whilst building a JSNI tutorial. With this in mind lets take a look inside one of the Logging implementations, the Firebug logger.

In a standard JavaScript application the following code would log a warning to the Firebug logging console:

 console.warn(message);

Unfortunately, since Java is a typed language, this console object isn't available to us, however GWT provides a way around this in the form of JSNI methods. JSNI methods provide a way for us to write JavaScript directly into GWT classes. For example, the following shows the JSNI method for logging a Firebug warning :

private static native void firebugWarn(String message) /*-{
 console.warn(message);
}-*/;

As you can see, the method is marked as native and the body of the method is enclosed in the /*- and -*/ markers, the code between which will be copied to the compiled GWT application.

The isFirebugAvailable method is another place JSNI is used to good effect. In the logging system I've used the "Object Detection" pattern to determine the browser logging capabilities, here's how this is used in the Firebug logger:

public static boolean isAvailable() {
 return isFirebugAvailable() && BrowserUtils.getUserAgent().contains("mozilla");
}

private static native boolean isFirebugAvailable() /*-{
 if (typeof console != "undefined") {
  return true;
 } else {
  return false;
 }
}-*/;

Here we're checking to see if the console object is available to us (it won't be if Firebug isn't installed), and as an extra check we make sure we're running on Firefox

Deferred Binding

This logging framework makes decisions regarding which logger to use at runtime, however GWT offers another solution known as Deferred Binding. Deferred Binding allows the compiler to make decisions as to what to include in the final application at compile time. For example, if the framework was to use deferred binding, the GWT compiler would produce a separate application for each instance of the Logger, each version ONLY including the logger for the particular browser version. The bootstrap code would check the browser version and load the correct version of the compiled JavaScript. The idea is that the resulting Javascript is not only faster (because certain decisions don't have to be made at runtime), but also smaller.

This sounds great on paper, however in reality it does lead to longer compile times, and if there are any other parts of the application also using Deferred Binding it can lead to quite a few versions (known as permutations in GWT) of the application being created. For example, if there is another Deferred Binding flag that's either on or off, the GWT compiler will create "Number of Loggers" 6 x 2 = 12 versions of the application!

Deferred binding has it's place, however since all the loggers are small and only one decision has to be made when the application starts, I decided Deferred Binding just wasn't worth the payoff.

And that's it!

Originally this post had a step by step code walk through, however I later cut it down to just focus on JSNI. If your interested in seeing just how the framework works then please feel free to download the Eclipse project here. Just a quick note about the project; I don't use the GWT application creator but create GWT project by hand and instead of the project including the GWT libraries I use an Eclipse library (called "GWT") added to the project classpath to bring in the GWT libraries.

Friday, June 19, 2009

GWT and Google Visualization API - Tip

Google Visualization is an excellent API for adding graphing capabilities to any web application. Recently a GWT wrapper has been released which makes it easy to embed this API into GWT applications. The GWT module is really a wrapper around the standard Visualization JavaScript libraries and in order for everything to work the documentation says the following line is required in your GWT module:

<script source="http://www.google.com/jsapi"/>

With this line in place everything does indeed work, however I recently discovered a problem. Adding this line into the GWT module has the unfortunate side effect of the script element appearing in the GWT bootstrap code; the result of which is the browser will fetch the JSAPI library before actually loading your GWT module. Under normal circumstances, (ie when connected to the Internet), this isn't a problem, however this JavaScript fetch can cause significant delays if your using GWT hosted mode, or even offline, (only a small part of the application is concerned with graphing so if this library isn't loaded it's no big deal).

The Solution

The solution is not to add the script to the module definition, but instead to add it programmatically when the module is loaded. The following code shows how this issue was solved:

 public void onModuleLoad() {
  addGoogleJSAPIScript();
 }

 private void addGoogleJSAPIScript() {
       ScriptElement script = Document.get().createScriptElement();
       script.setPropertyString("language", "javascript");
       script.setPropertyString("src", "http://www.google.com/jsapi");
       Document.get().getElementsByTagName("head").getItem(0).appendChild(script);
 }

This code should be straight forward, all it's really doing is creating an HTML <script> element and setting the Google URL. Once this is added the browser fetches the JSAPI library, but the crucial thing is that it doesn't fetch the library in the boot strapper, but rather when the main UI module library has been loaded

Friday, January 30, 2009

GWT, Internet Explorer and XMLHttpRequest Caching

This morning I spent over an hour tracking down and solving a client/server communication issue which I'm going to document here, for all weary travellers who come this way. The application in question uses the GWT RequestBuilder in order to make an HTTP GET request to the server. When running in GWT Hosted mode I have a relay servlet that acts as a proxy allowing me to test the application against the real server without breaking the browser same origin policy.

The Problem

When running the application I couldn't understand why the first request retrieved the correct JSON response, but any further requests only ever returned this same original response, when in fact they should have been very different. I tried all the obvious things such as accessing the server using a browser and the server appeared to be working correctly.

I finally tracked the issue down to the fact that on Vista GWT hosted mode uses Internet Explorer as its embedded browser. Unfortunately due to some bugs (thanks to this post which gave me the required pointers), Internet Explorer will cache XMLHttpRequests if they're for the same URL. As it happens, because I'm using a relay servlet, all the requests do indeed look like they are going to the same URL, and thus IE keeps returning the same response, without ever sending the request to the server.

The Solution

The solution (at least when using hosted mode), is to change the Internet Explorer cache settings (I'm using IE 7), which can be done by selecting Tools, Options and clicking the Browser History settings button, (I'm not sure why cache settings are in browser history section!):

In the resulting dialog, chosing "Check for newer pages Every time I visit a page", resolved the issue. I would certainly recommend modifying this setting even if your not using XMLHttpRequests as I've also had issues with style sheets getting stuck in the IE cache!

Note: this appears to be a Windows only issue, on Linux GWT hosted mode uses Mozilla, although it certainly would be nice to choose either IE or Mozilla on windows!

Saturday, January 24, 2009

Quick Tip : Getting Eclipse to help spot common errors

Since Java is a statically typed language, the compiler is pretty good at spotting errors, but sometimes we do things that are syntactically correct, but which are semantically wrong; take for example the following code sample.

public class TestError {
  String personName;

  public TestError(String personName) {
       personName = persionName;
  }

  public int getNameSize() {
       return personName.length();
  }
}

The above code contains a common mistake, namely that the parameter personName is hiding the class field personName; all that's really happening is the parameter is getting re-assigned the value it originally had. The main problem with this kind of mistake is that the developer assumes the object state is full initialized after calling the constructor, but on calling the (admittely worlds most pointless) getNameSize() method a NullPointerException would be thrown.

There are a few ways that the above code could be corrected in order for the compiler to spot the error. One way is to set the personName class field to final, which tells the compiler the personName field MUST be assigned a value in the constructor, and thus ensures the object state is intialized correctly, i.e.:

public class TestError {
    final String personName;

    public TestError(String personName) {
  personName = personName;
    }

    public int getNameSize() {
  return personName.length();
    }
}

The compiler will now throw a "Blank field Person may not have been initialize" error and compilation will fail. This is good (and you should certainly make as many fields as you can final), but it doesn't help if we want to actually update the person name in a later method.

Another way we can give a hint to the compiler is to make the personName parameter final:

public class TestError {
    String personName;
    
    public TestError(final String personName) {
         personName = personName;
    }
    
    public int getNameSize() {
         return personName.length();
    }
}

Now the compiler won't let us modify the personName parameter and will throw a "The local field variable personName cannot be assigned" error, and again stop compilation. Setting parameters to final is probably a good idea, and a good way to state your intention to the compiler, but we probably don't want to do this on EVERY method.

Luckily Eclipse can come to our aid by spotting this, and other common potential issues. If we look at the original code in the Eclipse editor we see this:

Notice the yellow warning underline underneath the parameter assignment. Eclipse is giving us a warning that "The assignment to variable personName has no effect" (you can check this by hovering over the margin marker); That's pretty useful, but we tend to get use to, or just don't see, warnings. What we want to do is have Eclipse scream at us here's a mistake and halt compilation; fortunately for this blog post, this can be done.

The trick lies in the depths of the Eclipse preferences under the Java section. The following image shows the full path:

In the resulting dialogue on the right hand side you'll see several sub-options, but the one we're interested in is the Potential programming problems; when expanded it looks as follows:

By default this dialogue has all the options set to warning or ignore, which results in Eclipse waving pathetically at us rather than screaming. The option that would have protected our original code is Assignment has no effect (eg 'x = x'):. If we set this to error, Eclipse will now halt all compilation until it's fixed; our original code now looks like this in the editor :

We've now found the error at compilation, rather than during testing, when it could be much harder to track down. There are lots more options within the potential programming problems section and I encourage you to take a look and set the relevant ones; you can find more information about each one by pressing F1 in the dialogue and reading the Eclipse help.

Warning

These Eclipse compiler options are indeed a great help but PLEASE don't use them as a short-cut to writing good defensive code! In the given example above, the best way to write the code is to make the personName field final which not only protects against the object being set up correctly, it also tells future developers the intent of the personName field.

Tuesday, January 20, 2009

Creating a GWT component

GWT widgets are the visible elements of a GWT application and so it's quite important to understand how they work. In a previous post I explained the rendering process but here we get a little less abstract by actually creating a simple GWT component. On the way we'll also look at using Java 1.5 Enums to great effect in order to reduce the amount of runtime errors our browser app may have.

I've called the component we're going to build the HtmlList, and as it's name might suggest it's simply displays a list (ordered, or unordered), in the browser. List items will have actions associated and will run these actions when the item is click. Finally list items will highlight as the mouse pointer moves over them.

Before we start, I'm making the assumption that you've got a GWT application running inside Eclipse. If you haven't, then simply use the GWT projectCreator and applicationCreator commands to create it, (my test application is called com.maddison.testapp.client.TestApp).

Creating the module

Since our HtmlList is going to be the next GWT killer component we obviously want to package it in a way which people can use it in their own applications, to do this we need to package it in a module. Modules are one of the building blocks of GWT applications, you can think of them in much the same way a library of classes. To create the module we do the following:

  1. Create a standard Java package that will hold our module, I'm going to call mine com.maddison.killerwidgets
  2. Create the client package which will hold the actual GWT code, this will be the same package but with client on the end, for example, mines called com.maddison.killerwidgets.client
  3. Now we can add the module descriptor which is a simple XML file that tells the GWT compiler all about our module.. Create a standard text file called KillerWidgets.gwt.xml in the com.maddison.killerwidgets package. For now use the following simple module definition, we'll be adding more to it later:
    <module>
     <inherits name='com.google.gwt.user.User'/>
    
    </module>
    

To recap, at the end of these steps, you should have a package structure that looks like so:

Creating the basic Widget

All GWT widgets are decended from com.google.gwt.user.client.ui and therefore our component class needs to extend this. Create a class in com.maddison.killerwidgets.client called HtmlList that extends com.google.gwt.user.client.ui.Widget. This will create possibly the dullest widget in the world since nothing will actually rendered.

Since all GWT widgets are simply Java classes, the first thing we need to do is give HtmlList a constructor. Remember that one of our requirements was the list could be rendered as either an ordered list (OL element), or an un-ordered list (UL element) and thus we need some way to tell the component which it's going to be. A simple way would be to pass in a boolean that if true creates an ordered list and if false, creates an unordered list .i.e. :

     public HtmlList(boolean orderedList) {
     }

This approach works, but it's not nice for two reasons:

  1. A user of the widget only sees that the constructor takes a boolean and then must understand what the boolean means. A call to this constructor would be new HtmlList(true), which isn't very clear to anybody who's never seen our fantastic component before
  2. The other is one of extendibility. Once our component is popular we may want to release version 2.0 which allows a list to be created on say a SPAN element. If we've used a boolean we only have two possible values and the interface to our component would have to be modified, breaking any existing code
The power of the Enum

Our HtmlList will use a Java 1.5 Enum (Enumerated Type) as the parameter to the constructor to indicate the type of list required. A simple Enum would look something like this:

 public enum ListType {
  UNORDERED, ORDERED
 }

Resulting in a constructor that looks as follows:

    public HtmlList(ListType listType) {
     switch(listType){
        case UNORDERED:
           // Create UL Element
           break;
        case ORDERED:
           // Create OL Element
           break;
     }
    }

That's better since a client would look something like new HtmlList(ListType.ORDERED) and a code reviewer can tell what type of list would be created without having to resort to JavaDocs; it's better, it can still be improved. Lets say for example in version 2.0 I do add the ability to host a list inside a SPAN element. I add the type to the ListType but in my rush to get Version 2.0 out the door I forget to update the constructor. There's no information to tell the compiler a switch case is missing and so it'll quite happly compile the Application and we ship it (although hopefully your Testing/QA proceedures are a bit firmer than that!)

What we want to do is force a developer to HAVE to add element creation if they update the Enum. This can be achieved by extending the ListType enumerated type to have methods as in the following code:

 public static enum ListType {
  UNORDERED {
   public Element createElement() {
    return Document.get().createULElement();
   }
  },
  ORDERED {
   public Element createElement() {
    return Document.get().createULElement();
   }
  };

  public abstract Element createElement();
 }

Most people are pretty comfortable with the basic Enum of values but probably haven't seen this approach before, which is a shame. Java 1.5 Enumerated types aren't just replacements for static Integers, they're fully blown classes in their own right. What the above Enum says is that each Enum value MUST have (because of the abstract keyword) a createElement method which returns an Element. The constructor for this now looks as follows.

 public HtmlList(ListType listType) {
  setElement(listType.createElement());
 }

This is now 100% safe, the compiler has the information to know that an Enum value must have a createElement and so it just won't compile the application if it's missing. Catching errors like this at compile time is much better than catching them later on in the development cycle, and quite a few of the improvements in Java 1.5 were designed around improving compile time checking.

If using Enums in this way is new to you, then I would certainly urge you to look at the Sun description of Enums, and if you have a copy of Joshua Blocs Effective Java (second edition) - and if not, why not? every Java developer SHOULD own a copy - check out Chapter 6 where he explains how these Enum types can be used to even greater effect.

Whilst this Enum stuff isn't something that's GWT specific, it does show the power of using GWT over straight JavaScript. Since Java is a statically typed language we get extra help from the compiler in ways that just wouldn't be possible with a JavaScript compiler.

After that digression, it's time update our component with the new Enum so that it looks as follows:

public class HtmlList extends Widget {
 public static enum ListType {
  UNORDERED {
   public Element createElement() {
    return Document.get().createULElement();
   }
  },
  ORDERED {
   public Element createElement() {
    return Document.get().createULElement();
   }
  };

  public abstract Element createElement();
 }

 public HtmlList(ListType listType) {
  setElement(listType.createElement());
 }
}

There are two things in this code that need explaining. The first is the createElement method that uses the GWT Document object, which is really GWT's abstraction layer over the browser HTML DOM. The second is the setElement method. This method is important as it tells GWT what element should represent this component in the HTML DOM. This method MUST be called when the Widget is created.

Adding Items

At this point we have a component that's created either an OL or UL element, not very exciting so lets add some list items. Our original requirments for list items was that they perform some action when clicked. There are two ways we could model this, one is to fire an event when an item is clicked, and let the component client respond to the event. The other way is to pass in a GWT Command object when adding the item, and call the Command.execute method when the item is clicked. Both of these are a matter of taste, but for simplicity we'll use the Command object pattern; which means adding the following addItem method to HtmlList:

    public void addItem(String text, Command command) {
  LIElement liElement = Document.get().createLIElement();
  liElement.setInnerText(text);
  getElement().appendChild(liElement);

  listItems.put(liElement, command);

  sinkEvents(Event.ONCLICK);
    }

Now things start to get a little juicy. The first line of this method creates the HTML LI element we've already seen this Document object at work previously. The second line sets the text of this LI element and the third line retrieves the element of this component (the element passed to setElement), and appends the LI element to it.

The next line stores the Command object away for later retrieval in a Map called listItems. We currently don't have this map defined, so add it to the top of the class as follows :

public class HtmlList extends Widget {
 private final Map listItems = new HashMap();

Java Tip: Although this is a HashMap implementation we're using, the actual field type is the generic interface Map. It's important to use the generic interface so that the implementation can be changed at a later date; I see a quite a bit of code where the actual implementation class is used as the field type!

The Map will be keyed on the actual LIElement which is safe to do because the GWT Element method contains an implementation of equals and hashCode

Meanwhile back in the addItem method we come to the final line sinkEvents(Event.ONCLICK). When out GWT Widget is created, it simply represents a normal HTML list, it won't receive any events. If this were a JavaScript object we would need to add the onClick event handler, and this is what the sinkEvents method is doing, it's telling GWT that we would like to know of any browser onClick events that happen on our (OL or UL) element.

Handling the event

When an event that we've declared in our sinkEvents happens, GWT will call the onBrowser event method, so we need to add the following method to HtmlList :

 @Override
 public void onBrowserEvent(Event event) {

  switch(event.getTypeInt()) {
   case Event.ONCLICK:
    Element target = event.getTarget();
    if (listItems.containsKey(target))
     DeferredCommand.addCommand(listItems.get(target));

    break;
  }
 }

Java Tip:Always use the @Override annotation, this is information to the compiler that this method should override the Widget.onBrowserEvent which provides extra help from the compiler against such nasty things as typing errors (which I appear to be prone too!).

The event object contains the getTypeInt method which informs us of the event that's happened. At the moment you'll notice that I'm handingly this in a Switch statement, this is because, not only is it easier to read and maintain (as apposed to using a large if-else if block), but we're also going to be adding more events to this later. If the event is a CLICK, we retrieve the target element and check to see if we have this elemented keyed in our command Map. Don't forget that events in Javascript (and thus GWT), bubble up so parent's will receive event notifications on child elements, in this case the LI element.

DeferredCommand

Once we've retrieved the Command object we add it to the special GWT DeferredCommand object which needs a little further explaination. It must be remembered that JavaScript is a single threaded language, if some event code is running all other code is blocked from running until it's finished. Now obviously we have no idea what Command the client is going to perform in the passed in Command object, it could be a short operation, or it could be a long running operation. If it's a long running operation and we simply called Command.execute() we wouldn't be able to return from the onBrowserEvent until after this operation has finished, and therefore we'd really lock up the UI. The DeferredCommand object tip toes around this problem by calling the Command.execute() method after 1ms which means our onBrowserEvent can return and later on the Command will be called back to use the JavaScript thread. Remembering that JavaScript is single threaded is VERY important and easily forgotten when your actually coding in a multi-threaded language such as Java. Further information on using DefferedCommand and other related objects can be found in the Google GWT help.

A quick test

At this point we should have a component that displays a list and runs a command when something is clicked. Before we go on and add more bells and whistles, it would be good to check that this widget works so far. To do this we'll just add it to the test application that the GWT applicationCreator.cmd command created, in my case that's TestApp and now looks like this:

  public void onModuleLoad() {
   HtmlList list = new HtmlList(ListType.ORDERED);
   list.addItem("Test 1", new Command() {
  public void execute() {
   Window.alert("You Selected Test 1");
  }
   });

   list.addItem("Test 2", new Command() {
   public void execute() {
    Window.alert("You Selected Test 2");
   }
    });

   RootPanel.get().add(list);
  }

This should be self explainatary, but really we're just creating an instance of an Ordered HtmlList and adding two items, both of which display an alert box if the item is clicked. Finally the HtmlList is added to the Body element of the browsers HTML document. Although this will compile inside Eclipse it won't compile with the GWTCompiler. That's because HtmlList is in another module (KillerWidgets), and thus we need to import it into our TestApp module; this is done in the TestApp.gwt.xml module definition. The following shows the KillerWidgets module being imported, the bold line is the one which was added :

      <!-- Other module inherits                                      -->

      <inherits name="com.maddison.killerwidgets.KillerWidgets"/>

      <!-- Specify the app entry point class.                         -->
      <entry-point class='com.maddison.testapp.client.TestApp'/>

Now the application is complete and we can use the GWT created TestApp.launch file to start it; simply right click on it and choose RunAs TestApp. The application as it stands so far is given here, clicking on a link displays the alert message:

Adding some Style

As you've noticed, when the cursor is moved over the list items it's still a text cursor, but we'll try and change that by injecting some style. Regardless of how fantastic GWT is, the platform it's deploying to is still at the end of the day Javascript+HTML+CSS, and therefore all GWT components use CSS rules in order to dictate how they should appear in the browser. In GWT stylesheets etc are all 'deployed' from the public directory of the module so lets add that now, by creating a directory and ListStyle.css file so that the package structure looks as follows:

And the contents of the ListStyle.css should look as follows:

 .html-list {
  list-style:inside;
  width:100px;
 }

 .html-list li {
  cursor: hand;
 }

Here any LI elements that are children of an element of class .html-list will have a hand cursor. In order that this style sheet stays with our module we need to update the KillerWidgets module definition to include the stylesheet element, i.e:

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

 <stylesheet src='ListStyle.css' />

</module>

And next we need to hook up the .html-list style to our component which is done using the setStylePrimaryName method of the GWT widget class. This makes our HtmlList constructor look as follows:

 public HtmlList(ListType listType) {
  setElement(listType.createElement());
  setStylePrimaryName("html-list");
 }

And when compiled gives us the following much more exciting application:

Adding further style

The last requirement of our component is that it should highlight the element the cursor is over. We'll implement this by applying a particular style whe onMouseOver is fired and remove this style when onMouseOut is fired. For this to work we obviously need a style, so I've added the following class to ListStyle.css:

.highlightOn {
 background-color:#cccccc;
}

Next we have to tell GWT that we're interested in further events and we do that by updating the sinkEvents line so that it looks as follows:

 sinkEvents(Event.ONMOUSEOVER | Event.ONMOUSEOUT | Event.ONCLICK);

And then extra cases to the onBrowserEvent switch statement to handle these new events:

   case Event.ONMOUSEOUT:
    event.getTarget().setClassName(null);
    break;

   case Event.ONMOUSEOVER:
    event.getTarget().setClassName("highlightOn");
    break;

This should be self explanitary, but really when an LI element triggers the ONMOUSEOVER event, it has the CSS style class highlighOn set in it's class attribute . Setting the className to null removes the style and resets the element back to what it was before

Finally compiling the test application gives the following:

Conclusion

This post has turned out to be a LOT bigger than I had planned, but hopefully it's given you a taste of how simple it is to build a GWT component; certainly this is just the tip of the iceberg

The full code for this post can be downloaded here

Saturday, January 17, 2009

London Underground Realtime Status Yahoo Pipe

Yahoo Pipes is something I've been meaning to get to grips with for quite a while but just never had the right application for it. However before heading home last night I did my quick check of the tube status page for any usual problems and it suddenly hit me, wouldn't it be great if this information was machine readable!

I raced home and checked around to see if something similar had already been created and found an existing pipe implementation. This existing implementation reads a Twitter feed that's feed from the excellent twitter tube tracker by Tom Morris. The problem is that the data isn't realtime and isn't in an easily usable form by another application.

After a late night I finally finished a new pipe implementation that extracts it's data directly from The tube realtime status page which means it's always up-to-date as well as being fast to run. The feed can be used as an RSS feed, supplying human readable information, in which case you see the following :

or it can be used as a JSON feed/Pipe source, in which case the information is broken down into further parts. As an example, here's an item from the JSON Feed:

         {
            "statusDescription":"Saturday 17 and Sunday 18 January, suspended between Barking and Upminster. Two rail replacement bus services operate.",
            "status":"Part closure",
            "content":null,
            "id":"district",
            "title":"District",
            "description":"Part closure |  Saturday 17 and Sunday 18 January, suspended between Barking and Upminster. Two rail replacement bus services operate."
         }

As you can see, further item elements are available such as Status (general status), StatusDescription (further information) and id (a unique id for this line).

The London Tube Realtime Status pipe can be found here : http://pipes.yahoo.com/pipes/pipe.info?_id=c4feb5c6dea54a73500f8bb2f17912f6.

Hopefully it'll be useful to somebody, certainly I learnt A LOT about Yahoo Pipes whilst building it (which was the general aim after all)