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
_______________________________________________
xul-talk mailing list
xul-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xul-talk
