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.