Such of the innovation in programming in recent years has involved loose coupling. The invention of database driver methodologies such as JDBC and ODBC led to applications being loosely coupled with their back end databases, allowing best-of-breed databases to be chosen?and swapped out when necessary?without any ill-effect on the user interface. In the bad old days when the user interface was part of the data engine, an update to the database would require an extensive rewrite of the GUI.

Similarly, the decoupling of data and presentation in HTML?by using XML for the data and XSLT for the presentation of data?has led to much innovation and flexibility, not least of which is the ability to deliver a document as data in XML and deliver custom styling for that document with different XSLTs.

The next big trend in decoupling appears to be separating the user interface implementation from the user interface definition. There are countless initiatives, both open source and commercial, that will have at their core this very principle. The next big revolution in the desktop Windows operating system from Microsoft, codenamed Longhorn, is perhaps the most notable of these. With this type of decoupling, when a user interface is defined in a document such as XML, users would not have to download and install their GUIs; they can simply browse them as easily as they browse Web pages. A runtime engine would be present on the desktop, and servers would be able to deliver the GUI to the browser with an XML document.

This will be huge for the corporate environment where at present, rich desktops are difficult and expensive to produce and maintain. Corporations are necessarily paranoid about allowing users to download and install binary files, and in general block users from doing this. The only options are to build a rich interface in HTML, or to build Windows applications and install them using a CD.

Building rich applications in HTML or DHTML is feasible, but suffers from a number of drawbacks. First, an application written in these languages is interpreted by the browser, which isn’t optimized for running applications. Browsers are of course designed to render content; having scripted, parsed applications run within their context is an afterthought, and as such is very slow. Second, once the application is designed and coded, should you want to present a similar application to another customer?branded and designed according to their styles and tastes or to coordinate with their existing systems?a rewrite of the application is usually necessary. The world is becoming used to XML driving HTML, with XSLT stylesheets to brand the data differently for different users.

So why should more complex user interfaces be any different? They shouldn’t, and that’s the philosophy behind these new initiatives, including Longhorn, which will have its user interfaces defined using a language called XAML (XML Application Markup Language). In short, if a user interface is defined using XML as opposed to programmed using something such as C# or Java, then a runtime engine can parse it and render it on screen. Hooks within the XML could link to server-side applications that process information.

A Better Way
Java applets were originally designed to fill this role, but they are now used infrequently, as difficulties with versions of the runtime engine, technical issues with running Java in Windows, and performance issues with AWT and Swing led many to become disenchanted with the technology. Interestingly, the architecture of Java applets is very similar to XML-GUI, consisting of a run-time rendering engine (analogous to the JRE) that downloads and runs data over HTTP.

ActiveX on the other hand was designed for a number of purposes, one of which is downloadable user interfaces. Further, ActiveX Documents, which were part of Visual Studio 6.0, was a pioneering concept but security considerations regarding downloadable applications having full reign on the operating system and the hard drive have generally been a showstopper for this technology.

With XML-GUI, there is a single runtime engine running on the client desktop. (With Longhorn, this will be part of the operating system; with others, it is a downloadable, installable binary.) You only need to do one download for the runtime, and then every subsequent download is firewall-friendly.

This need for a downloadable binary in the current implementations of XML-GUI such as Bambookit or XWT may appear to be a showstopper for the same reasons as was Java applets or ActiveX controls. Indeed the architecture is very similar, but there is a subtle difference.

In the case of Bambookit, you have a Java applet that provides the Java runtime engine. This has to be installed once, and can be installed with a known JDK/JRE upon which it works. All GUIs are then rendered by this engine. Previously, when every GUI was an independent applet, you faced two problems. The first was that different applets could be targeted at different JDK/JREs, and the second was that you had no guarantee that the optimal version JDK/JRE for your GUI was installed at your client site, or that every instance of the JDK/JRE was the same at each client machine. XML-GUI effectively runs on a virtual machine on top of another virtual machine, and that level of abstraction should give you enough flexibility to control your dependencies more effectively. A similar argument exists for the ActiveX-based rendering engines such as the one with XWT.

As mentioned above, the XAML runtime for Microsoft Longhorn will be a part of the operating system itself, so all you will have to do to deliver a UI will be to deliver the XML document, and not have to worry about the runtime.

Inspecting Bambookit
There are too many initiatives out there to cover them all in this article, and more are being added daily. Some of the better known ones are XUL (XML User interface Language) and XWT (XML Windowing Toolkit) in the open source community, and Bambookit?a commercial offering. Links to various implementations are included at the end of this article.

Bambookit is a particularly impressive implementation as it is very easy to use and gives some great functionality and the ability to build complex, visually appealing, and high-performing user interfaces.

The XML file below draws a simple Bambookit GUI, containing a combo box:

To create the demo user interface in this article, download the evaluation of Bambookit from their Web site. This implementation is fully functional except that you cannot host Bambookit user interfaces from a Web server with it. Once you have downloaded it, unzip it to a directory named c:ambookit on your hard drive.

Save the XML file above as combobox.xml in the c:ambookit directory and then create an HTML file called combobox.html in the same directory containing the following code:

This code simply loads the runtime rendering engine of Bambookit from the JAR file bamboo_20.jar and points it at the xml file containing the definition of the desired user interface. The line of code that handles this operation is:

The user interface generated from the above code is shown in Figure 1.

This is a pretty simple demonstration, showing off how one can begin to build user interfaces with the toolkit. There are many more widgets available that can be used to build an interface with all the standard controls, text boxes, check boxes, buttons, tabbed dialogs, lists, treeviews, tables, and many more.

One thing that is very cool about Bambookit is that this loadgui parameter may point at a Web server, calling a service that delivers this XML. This may be a Web service (provided it gives a HTTP-Get interface), a servlet, an ASP or JSP page, or even a PHP script.

To change the source for your GUI, simply change the value attribute to point at your desired source file.

In this case you would replace the reference with whatever your actual service is. This opens up the possibility of automatically generating UI code from a server-side process.

For example, in the XML from the sample app above, the specifics of the contents of the combo box could be pulled from a database and returned as Bambookit format XML by, for example a Web service, a servlet, or a PHP script.

Retrieving from a Delivery Service
In an earlier article, I showed you how to build an XML delivery service using PHP, Apache, and MySQL. This service delivered the results of a query to a MySQL database in XML. To see Bambookit in action it would be a good idea to work through that article and set up the XML retrieval service that it steps you through. You can then enhance that service with the xml.php file that is in the download for this article.

The update adds a new parameter gui= to the service parameter list that, when set to ‘y’ (for ‘yes’), generates a Bambookit XML file containing the definition for a table.

To understand this code, you first have to understand how Bambookit defines a table. The schema is below:

. .

As you can see from the schema, Bambookit defines a table to be a collection of lists. Each column in the table is represented by a list. This can lead to a problem when, for example, you resize a column. In a table you would expect the rest to follow suit, but in Bambookit they will not unless you attach them to each other. The property attachToWidget achieves this. You simply specify the second column as attached to the first, the third to the second etc. and Bambookit will render the columns as a table. The PHP script in the downloadable source code for this article will do this for you.

In the download you will also see a sample XML file called table.xml. Examine it closely to see the relationships within the nodes defined within the XML attributes such as attachToWidget.

The HTML file is exactly like the HTML from the combo box example above. It simply contains an applet reference that loads the GUI definition from the PHP service. When rendered in Internet Explorer, it will display a table like that in Figure 2, above.

The example helps show how Bambookit adds a lot of value. The table has resizable columns and is sortable by clicking on the column headers in the way that is familiar to Windows Explorer users. Clicking on the column toggles between an ascending and descending sort.

This saves a lot of coding on the part of the user, and as it is Java based, it is cross platform by definition. To develop user interaction to enhance the base functionality derived from the Bambookit widgets there are a number of actions that can be set based on known stimuli. Check the Bambookit documentation for more details.

Community-built XWT
Another player in this space is XWT, an open source initiative that you can download XWT. XWT gives you either a Java-based or ActiveX-based runtime, and has the peculiar implementation of having to run off a server. This means that the XWT runtime has to be on a server and the configuration that you want to launch is passed to that server as a parameter. The configuration is an XML file, but it has to be zipped up in a special .XWAR file along with all of its dependencies. You then launch your application using http://server_hosting_runtime/URI_of_XWAR.

XWT has a flexible scripting model, using Javascript to process actions instead of the property pattern that Bambookit utilizes. It can also communicate with middleware using RPC or SOAP.

It may turn out that the flurry of activity around this concept is pointing towards an important future for developers. With the decoupling of presentation from implementation, new skillsets will need to be learned. At present, hand-coding of the XML documents to define the interfaces?lor the middleware servers to generate the interfaces?is still necessary, but as time unfolds, IDE packages will have UI designers that compile to an XML format. With no firm standard currently in place, it remains to be seen what that format will be.