tags:

views:

611

answers:

7

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.

+1  A: 

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

Draemon
The problem is that we have to access with the client devices (i.e. invoice printer, card reader) which is hard to achieve through a browser.
MrG
invoice printers and card readers have a GUI?
R. Bemrose
can you not use an applet for accessing the client devices? (with the right security settings of course)
Draemon
I see we're downvoting perfectly reasonable answers without reasoning. Care to elaborate?
Draemon
A: 

Try QT Jambi. This allows you to build form layouts in QT Designer and export them as a descriptor file of the sort you described.

ConcernedOfTunbridgeWells
This uses JNI - would this be available on something like a Mac?
jamesh
Check Troll Tech's web page. QT runs on Windows, Linux, OSX and quite a few different flavours of Unix. OTOH I don't know whether Jambi is available for OSX but the web site should say.
ConcernedOfTunbridgeWells
+2  A: 

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

macropas
+1  A: 

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.

JeeBee
+2  A: 

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.

jamesh
+1  A: 

There are quite a few XUL based toolkits for a variety of languages, including Java. I think Thinlet does a very simplistic XUL for Java, but there should be others.

Uri
+1  A: 

Basically you are sending serialized forms to the client, and serializing the resulting data. This could be done with Java serialization, i.e., RMI, but firewalls and so forth can complicate use of RMI on the Internet.

If you want to use XML over HTTP on the wire, you might take a look at java.beans.XMLEncoder. XMLEncoder is oriented toward serialization of UI components, but it works just as well to serialize POJOs. These would essentially be the model objects that are populated with user input in the FAT client.

erickson