There are many annoying things about rendering web pages with HTML. When you are writing corporate web applications, being stuck with HTML for showing lists of things is a problem. Especially when you need to allow users to select items in a list or otherwise perform operations on them. You end up resorting to one of three solutions:

1. Render everything as a paged table, adding checkboxes to each line;
2. Use a huge unwieldy Javascript library to provide grid-like functionality, then hope that it works;
3. Render the list as a select, then lay everything out with monospaced fonts and loads of non-breaking spaces.

Until now, we’ve used the third option. But this has four drawbacks:

1. It’s slow to load due to the amount of time taken to format each item, and the overhead in creating specific option tags for each line;
2. Adding or removing columns is time consuming from a development viewpoint;
3. Lists cannot readily reformat to cope with the size of window;
4. You can’t double-click an item.

Earlier this year we made an important decision to only support Firefox for the administrator backend of a web application we are writing. This took a load of worry off of us, and allowed us to concentrate on the application. But this decision has one unexpected benefit. So, I present The Christmas Project That Never Was:

Firefox and Thunderbird use a lot of XUL. This is the XML User Interface Language. Usually, entire web applications are written using XUL, pulling data from an RDF file. RDF is great for huge or static lists of information that need to be shared or used amongst different types of users. Amazon have an RDF feed. Mozilla histories and bookmarks are stored in RDF. You get the idea. RDF sensibly uses the concept of templates to render repeating sections of content. So basically, you create your RDF, and point the XUL file – which contains the template – at the RDF.

Now, my idea was to replace the HTML select for one of the views in our application with XUL. There were a couple of technical hurdles that needed to be covered:

1. How to embed XUL inside HTML;
2. Creating the RDF feed;
3. Interacting with the application.

Embedding XUL inside HTML. This is easy, just create an IFRAME and point it to the XUL source file.

Creating the RDF feed. Hmm.. have you ever looked at an RDF? It’s an XML file, which means loads of descriptive stuff identifying every nut and bolt. This web application could either a) create an RDF everytime the corresponding database is changed, or b) create a specific RDF file on demand when data is requested. Both of these are crap ideas. The application database changes frequently. Much more frequently than, say, the RDF feed from Amazon. After all, books don’t change their price every five minutes. Then there’s the caching. Oh yes, RDF’s are cached. Great. Not. So you have to invalidate the cache and rebuild the XUL view. Grr..

My next thought was to populate the XUL programmatically. But instead of the overhead in bringing all those pesky non-breaking spaces to the client, you have all the treeitem and treecell stuff. No great benefit.

So I ended up binning the RDF idea and went for Javascript instead. XUL trees, like all XUL, have their own bunch of scriptable objects. This allows you to write Javascript to populate XUL. Furthermore, XUL trees can have their own custom tree model where you basically write Javascript that satisfies all the interfaces. The approach I chose was to define a tree model. This would allow re-use throughout the rest of the application, whilst ensuring a very low-overhead in the amount of Javascript required to populate each tree. All the XUL file has to do is call a parent Javascript function to do the population.

Interacting with the application. Provided that you work out how the parent HTML page and the child XUL need to find each other, interaction is easy. The only difficult arises when passing results of selections from a tree to the application. PHP passes multiple selections as an array, but of course with the XUL tree this isn’t going to happen because there is no concept of a form with XUL, so you have to retrieve the data and populate the form for yourself, ready for sending back to the application. I admit, there are better technical solutions, but none would have allowed such easy integration. The bare minimum is to have an event listener registered to the select event and find out what has been selected.

Once all of this is sorted, the final step is the CSS. And, getting around all the default styling provided by Firefox. Especially the change in colour of selected rows when a tree becomes un-focused. The result is something like the following:

There are plenty of other things you get for free, if you want: fixed or variable columns, column dragging, hiding and resizing, tooltips. All and any of these can be made to persist, thereby allowing specific users to customise to their viewing requirements. You know Thunderbird, right? Same difference.