Java XUL Toolkit Review

For a project I was looking at options for rich client solutions for java programs. There virtually hundreds of options for that in the java world but it boils down to about a dozen toolkits that are realistically feasable for actual application usage.

While looking over the options I had to notice some sharp differences in the characteristics of rich client java toolkit solutions. Note that I am only looking at XUL toolkits which have an XML description of the view presented to the application user (and which can be modified without touching the logic of the application).

server-hosted or client-hosted

Most rich client solutions in the java world happen to be server-hosted: the toolkit makes a strict requirement like jboss or tomcat. The toolkit is a module that is going to be plugged into the application bus of those server kits. In essence you can not run the application without it. Some toolkit maintainers claim to provide a client-side server which provides some kind of runtime environment that can load a module but it is actually never the real same thing: the functionality of the application is going to work different than described for the server-hosted environment.

the thing between screen view and application logic

The thing in between can be called the "binding". Some toolkits require the server-side to instantation binding-objects that react to an event-queue. An XUL "action" will only send an event with name. Other toolkits have actions in the client-side that can bind directly to function names and data items. And the last option has a third layer inbetween that couples attributes in the client-side view to functionality of the server-side code.

the extension and reach-through capabilities

There is usually a lack of documentation telling about options to extend the view options - while most tell about how to register a new tag in the XUL format there is hardly anything how to register an attribute in the view and how to register binding objects that can link attributes and actions in the view to functions of the application. Some even miss to describe options how an application can directly ask the client-side for current attributes or the way that a binding layer can link back to application nested objects.

the disconnect principle

Some toolkits do represent the gui widgets directly in the namespace of the application in which case they are about the same. If you would know the base "this" pointer of the logic objects and the view frame then you could reach through easily. In another scenario you do want the client and server to be on different processors - and you want to allow the network to temporarily fail in between access. Just think of an html form that is loaded in one step from the server, the user can modify the fields offline, and post the html form to the server when done. It seems that some toolkits want to model an artificial gap between client view and server code where they fail to allow the client to run disconnected.

Thinlet

The best toolkit to learn about the benefits is "thinlet" (at thinlet.com). This toolkit fits into 50k spread over three classes. The instantiation of a view for an application is three lines of real code. The examples are easy to guess - action-names link directly to application code functions where the arguments are simple java types or a widget type: it is completely oriented on attributes - no "listener" glue code is required.

The hardest omission is the failure to desribe any application view that spans over multiple windows. The toolkit itself is implemented over the old AWT widget set without the filechooser - it would open a modal dialog but that breaks the model of thinlet that transparently "bind"s view attributes to application functions. The ease of bindings is also its burden.

Through a little patch I was able to popup dialogs by allowing the server side code to create a modal dialog - and there are other examples that show the essiantial mode of the server application to bind multiple view frames. In essence you could not move one view attribute across view instances. However that is not so far away from pure java code creating a series of gui objects. The XUL helps dramatically with that.

SwiXML

The SwiXML is the grand cousin of thinlet. Instead of being reduced to a limited set of widgets and attributes it brings about all the virtual attributes of a swing widget and all the possible actions and event hooks. Adding a new widget sounds easy so there should be no problem to port complex swing guis to the XUL of SwiXML.

On the other hand the server code is required to hook into the event queue of the view frame. Since java knows many widget-specific action-listeners it does also make the bindings inside the application code to be specific to each of the swing widgets in use. Unlike thinlet you can not expect a string or int but you have to write an anonymous object of the listener types that extracts a simple-typed attribute from an incoming event type.

That requires some internal knowledge about swing - but you will also hear high praise of people coming out of the swing area to XUL-based widget drawing. The SwiXML can export all stuff of its underlying widgetry with a code size similar to thinlet.

Genesis

Genesis is among the ambitious projects that you should have a look at - it does show how to provide a middle layer for the binding of view attributes (and events) to the application code functionality. It does also have provisions for aspect-oriented programming that is such a hot topic these days. It's simply a cool project.

What might be missing is the community support for genesis, missing tutorials and such stuff. The site looks like a one-man project that has a tendency to describe the cool features missing some everyday task that one can copy-n-paste as boilerplate code to get started.

And it has some server-dependencies *sigh*

JellySwing

But Genesis is not the big one in terms of dependencies and size. The real big one is jelly. And it does also require to twist your mind when thinking about XUL: originally it is like an html form that is being drawn with real gui widgets (the graphic-"rich" widgets). Each xml element is a widget that has attributes plus events that it can emit / receive due to actions of the user or changes in the application.

However, jelly is not a document description with attribute places to be filled in. It is an xml-based scripting language. Therefore, an "action"-attribute of a widget element does not name an client-side event or a server-side function: it is a client-side expression that can reference client-side functions, i.e. scripted functions. From glancing over the jelly documention I have not seen a hint how to import any server-side functionality or anything like importing functions implemented in java itself - everything seems to be a jelly-script.

The real great thing here is the taglibs of jelly: it does virtually transpose any apache commons library to xml elements to be used in jelly-script. Since jelly is expressed in xml it is easy to mix any xml descriptions of user interface but the user gets lost on the way to know the bindings. You do have to learn a completely new programming language, so there is NO easy start for either java people, swing people, or html forms people. Perhaps javascript / dynamic html people might get a clue but it looks very overdone.

My Wishes

If you would allow me to wish: I would like to see the application code to be as simple as in "thinlet" where it does only need to handle simple-typed objects (or widget-type or xml-type). There should be a layer inbetween that can transpose client-side widget-events. Other than thinlet it should be easy to extend the widgetry and binding logic.

SwiXML shows how easy it can be to transpose new widgetry and Genesis has a nifty concept to extend the binding logic while still allowing the application to be left simple. For an actual fact nobody needs the overdone client-side logic work of jelly. The "hello world, who are you" example should be an xml file of six lines - not sixty lines as in jellySwing.

So, my wishes would be to a heavy-retroinspection toolkit that allows to import java (widget) library with xml code that can be xml-included (hello xmlns). That is only glue code for the binding which would not require the dozen heavy-weight depencies of jelly - just an xml parser and bean support with a little expression language. And the binding of multiple application objects is done via the client-side descriptions (server-side triggers just them).

Postscriptum

Recently I have stumbled over JDNC which happens to provide a framework to connect an xml description of a swing-based gui (rich client) to a backend based on java beans (data-centric). It is currently at version 0.7 and poorly document (just a number of design goals).