Java GUI described in XML

Question

My company currently evaluates the development of a Java FAT client. It should support a dynamic GUI and has as much logic as possible on the server side. Hence the idea came up to send the screen as XML to the FAT client, show it to the user and send the entered data similar to "html form" back in a structure like:

<fields>
  <field type="checkbox" name="active" checked="false" x="10" y="10" />
  <field type="textbox" name="username" value="dummy" x="10" y="30" />
  <field type="selection" name="group" selectedIndex="1" x="10" y="50">
     <data index="0">user</data>
     <data index="1">admin</data>
  </field>
  <field type="button" name="ok" x="10" y="70" />
  <field type="button" name="cancel" x="10" y="90" />
</field>

Background
The sponsor is looking for an data entry and review application which they can adapt to their needs by simply changing the configuration. Hence we have to provide a possibility for their administrators to design so called "screens" (aka forms) and provide a client/server system enabling them to distribute those to their end users. Incoming data (i.e. data entered by an user) will be then forwarded to an already existing workflow engine which is handling the business logic.

Question
Has anybody out there developed something similar? Which libraries would you suggest? Any pro & cons? Many thanks!

Update
Many thanks for your input, Thinlet looks very promising as well as JavaFX - I will look into both.

Answer 1

When I last looked for such a thing, two options were Thinlet and Apache Jelly.

The plus points were that you could separate the wiring and construction of your application from the behaviour. I'm not sure of the viability of either of them to do this, but I guess there could be some functionality for translating into another toolkit, much as Lazlo can translate into AJAX and Flash.

Before I found these, I had written a similar toolkit (when Echo was the cutting edge, and Java 1.3 was bleeding edge), based upon the JHTMLEditor. It worked, but listeners were running in the same VM as the renderer.

Which brings up the point that @Draemon makes, in a client/server context, I would have to ask if this is a fruitful way to solve the larger problem. I am guessing that you want to offload a lot of CPU cycles onto the client? Perhaps if you add a bit more, we can make more suggestions? This does point to an approach where your application is deployed on the desktop as a localhost webserver, and you serve pages to a local browser.

If you can wait, I would, and wait for JavaFX, as this will make building applets a good deal more declarative, and will also cut down on the initial download of the rendering library.

Answer 2

"It should support a dynamic GUI and has as much logic as possible on the server side."

What you're describing is a web app. The client is already written (the browser) and the XML (ish) format is (X)HTML.

It would be possible to recreate this process using your own XML format and your own client, but I don't see why this is necessary or desirable.

Answer 3

Try JavaFX ( Wikipedia about JavaFX ). It's not XML, but it's easy and declarative too.

Answer 4

Have done something similar with SWT, although that was converting a logical data structure (in this case an application form model) into a GUI, rather than specifying the GUI directly. This allowed us to refactor the GUI depending on the client properties (PocketPC or Desktop) because the data model was semantic rather than dictatorial about layout.

Writing XML parsers and generators is simple. Writing something to generate an interface from a model is less simple, as you do need to store relationships between GUI elements and the model fields that they relate to so you can update them when a change is made, rather than the usual hardcoded Listener on each GUI element.