Java XML UI Language (XUL) Toolkit Review - Comments?

Gerald Bauer <[email protected]> Tue, 19 Jul 2005 16:50:52 -0700
Newsgroups gmane.comp.lang.xul.general
Message-ID <[email protected]>
Hello,

   Guido Draheim has recently published a report titled "Java XUL 
Toolkit Review" that evaluates open source projects that let you build 
rich client Java solutions using markup. The projects covered include 
Thinlet, SwiXML, Genesis and JellySwing.

  Guido writes:

   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).

  o  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.

 o  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.

 o  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.

  o  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.

  ....

  More @ http://www.informatik.hu-berlin.de/~draheim/java/xulkits.html

   If anyone is using a markup-based project for build rich client 
solutions, let us know what open source toolkit you use.

   - Gerald


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click