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)

Monday, January 12, 2009

Browsers and the HTML specification

We're all told that browsers differ in their interpretation and rendering of HTML but sometimes it's hard to find a simple concrete example. Recently I decided to remind myself of everything HTML has to offer and re-read the HTML 4 specification. The HTML 4 specification was published in 1999 so you'd think that all current modern browsers would support it fully, but you would be very wrong.

The example here uses the Q or quote element, a very simple HTML element designed to put quotation marks around text, here's the description from page 93 of the HTML 4 specification PDF:

"Visual user agents must ensure that the content of the Q element is rendered with delimiting quotation marks. Authors should not put quotation marks at the beginning and end of the content of a Q element."

Now I'll agree that the Q element isn't the most exciting in the world, but you'd think that because it's so simple, all browsers would have no trouble with it. What I found though was that none of the browsers where consistent in rendering the Q element correctly. As reference, for this experiment I was using the following Windows browsers:

BrowserVersion
Internet Explorer7.0.6001.1800
FireFox2.0.0.14
Opera9.63
Google Chrome1.0.154.36

Simple Test

The first test was just a simple insertion of a Q element, for example <Q>This is a quote</Q>, the expected output is that the browser would render it as "This is a quote". The following shows the results :

Rendering of a simple Q element
BrowserImage of rendered text
Internet Explorer
FireFox
Opera
Google Chrome

As you can see, there are differences already, but almost all browsers render what we would expect, all except one, Internet Explorer. That isn't a mistake, IE really does just ignore the Q element and no amount of massaging could get it to work. Lets remember that the HTML 4 specification was published in 1999, and Internet explorer has had several versions since then, you'd think it would be able to render something as simple as a quotation mark. Anyway, lets move on to test two.

Embedded Quotations

The HTML 4 Specification makes it quite clear how browsers should render quotations within quotations:

"User agents should render quotation marks in a language-sensitive manner (see the lang attribute). Many languages adopt different quotation styles for outer and inner (nested) quotations, which should be respected by user-agents."

and the following statement

Since the language of both quotations is American English, user agents should render them appropriately, for example with single quote marks around the inner quotation and double quote marks around the outer quotation.

The following table shows how each browser handles this requirement of rendering the inner quotation marks correctly:

Rendering of inner and outer Q elements
BrowserImage of rendered text
Internet Explorer
FireFox
Opera
Google Chrome

Here we can see that not all browsers fare equally, and we can also see that the lazy Internet Explorer doesn't even attempt to render anything. The only browser that renders this text exactly as expected in the HTML 4 specification is FireFox, the rest use the same quotes for inner and outer quotation marks which is wrong.

Style Sheets

The final test uses the CSS2 quotes property in order to modify the quotes used and see how the browsers fare. The follwing is the CSS style we're going to use is here, and just so it doesn't effect all Q elements, it has an ID selector.

Q#QuoteTest { quotes: "«" "»" "<" ">" }

This example is taken direct from the CSS2 specification and specifies that << and >> should be used on outer quotes, and < and > should be used on inner quotes. The table shows the results.

Rendering of Q with quotes property
BrowserImage of rendered text
Internet Explorer
FireFox
Opera
Google Chrome

As usual IE didn't even bother to try, and strangely Chrome ignored the property all together. It's nice to see that FireFox and Opera did render the text exactly as the specification says

CSS before and after properties

Whilst we're on the subject of CSS selectors, it's probably worth just trying out the before and after CSS properties which the CSS2 specification suggests can be used on BlockQuote (the block element version of Q) to provide quotation marks. The actual CSS looks like this :

BlockQuote:before { content: open-quote }
BlockQuote:after { content: close-quote }


Rendering of BlockQuote with open-quote close-quote content
BrowserImage of rendered text
Internet Explorer
FireFox
Opera
Google Chrome

Here we can see that once again FireFox is the only browser to correctly render the text. Opera made a good stab and obviously recognised the open-quote, close-quote content properties, but was let down by the fact it doesn't change the inner quotes. Surprisingly Chrome doesn't appear to have recognised the open-quote, close-quote properties and not very surprisingly, IE ignored everything!

I did perform one other test to see if the browsers do actually support the before and after pseudo classes using the following rules:

BlockQuote#extraTest:before { content:"{"}
BlockQuote#extraTest:after { content:"}" }

Every browser correctly added { and } around the block quote, except one, yep Internet Explorer, the Web's most popular browser still refused follow any standard.

My aim here wasn't really to test the Quote capabilities of the browsers, but really to highlight how different each browser is with something as simple as adding quotation marks. If browsers can't even render something this simple consistently, what chance is there that they will all render much more complex things correctly? What IS surprising to me is that Internet Explorer is just so damn bad, it refuses to render elements that have been in the HTML specification for 9 years as well as any standard CSS rules.

If you want to see how your browser works with these tests, I've put my test page up here.

Thursday, January 08, 2009

Finding Duplicate Files

I take quite a few photos, admittedly not as many as I'd like, but that's another story. All these photos need to be stored somewhere which leads to an escalating amount of disk/backup space being used. Over the years there has been the inevitable copy made of a photo, along with re-importing the same photos again from an SD card that wasn't cleaned down. All these leads to quite a bit of disk space usage that I'm pretty sure is just duplicate stuff.

Since I'm developer I decided I can fix this and so with my new found love of Python I cracked open PyDev and set to work; the result of which is attached. It's a simple command that will search a given directory tree and report on any duplicate files it finds. Duplicates are identified, not by name or date, but rather by creating an MD5 hash of each file and comparing the hash. Usage is as follows :

     python FindDuplicates.py [directory]

If no directory is specified, the current directory is used. The script will dump out the duplicates it finds after either searching the directory tree, or when CTRL+C is pressed. A sample of the output is here:

Searching: c:\temp\demo
Found Duplicates :
        Hash 37b170a11bc7a2f83ffe5fb5d39dd676 :
                c:\temp\demo\Autumn Leaves.jpg
                c:\temp\demo\DuplicateOfAutumnLeaves.jpg
                c:\temp\demo\ThisIsADuplicate.jpg
        Hash 6a83579dd334d128ffd15582e6006795 :
                c:\temp\demo\AnotherDuplicate.jpg
                c:\temp\demo\Toco Toucan.jpg

I'm pretty pleased with the outcome and learnt some nice Python as a result, feel free to use it in anyway you see fit.

FindDuplicates.zip

Friday, January 02, 2009

Using Eclipse Debugger With GWT

GWT uses CSS styling in order to format rendered widgets, but since your abstracted away from the underlying DOM, it can sometimes be hard to create the exact CSS rule.  I recently created a composite GXT component and as a result couldn't quite get the CSS rule correct, (as it turns out, it was a rogue DIV element messing things up).  The following shows how to use some advanced features of the Eclipse debugger, with a GWT application running in hosted mode, in order to see the HTML that's rendered for a GWT widget.
  1. First we need to set a breakpoint at the correct position in the code.  For this we open ComplexPanel: press CTRL+SHIFT+T and enter ComplexPanel and press OK
  2. Press CTRL+O and type "add", this will show the add(Widget, Element) method, press enter to jump to it
  3. On line 86 (the adopt call) right click in the margin and choose Toggle Breakpoint Setting Breakpoint
  4. Once the breakpoint has been set, right click on the breakpoint marker (blue dot in margin) and select breakpoint properties
  5. In the breakpoint dialog, click Enable Condition : Enable Condition
  6. The enable condition allows the breakpoint to only be triggered when the condition is met.  In the Condition box, enter "this instanceof RootPanel".  This is because ComplexPanel::Add will be called for all panels, but we're only interested in the point where a widget is added to the RootPanel. Breakpoint Condition
  7. Click OK and use the GWT launcher configuration to start a hosted mode session in debug mode.
  8. When the breakpoint activates, Eclipse will change to the debug perspective, stopping at line 86:  Breakpoint Triggered
  9. Press F6 to step over the adopt call, which we need to do in order to setup the child.  (If you remember from a previous post it's only in the adopt call where the Widget::setParent is called and the whole attach process begins.) Step Over
  10. Now we need to see the child DOM HTML element which we can do with the fantastic Debug Display view.  Bring up the display view by selecting Window -> Show View -> Display
  11. The display view will open (possibly at the bottom of the screen).  The display view allows any Java code to be executed, so we'll use it to call the GWT DOM.toString method which takes an element and displays the elements DOM as a string.  Go to the display view and enter DOM followed by CTRL+SPACE which will bring up the auto complete box. Select the com.google.gwt.user.client.DOM class. Selecting DOM
  12. Finish off the call to DOM.toString as follows :  Step Over
  13. Now we can execute the statement by highlighting the whole thing and clicking on the execute selected text (or pressing CTRL+SHIFT+D): Execute Selected Statement
  14. Once executed, the DOM will be displayed : DOM Complete
  15. To carry on with your application, press F8, the program will break next time something is added to the RootPanel