JSF versus XFORMS

[Byron Estes]

How does JSF compare to XFORMS?

How are they similar and disimlar?

It's been over 3-4 years ago since I played with an idea to create a generic applet that could connect to a controller servlet which would send back metadata that described a screen with a layout, conceptual gui widgets, and data to populate each with...

I think I started with serializing the Swing based screen from the server to the client, which worked, but as you can imagine performed horribly.

I then switched to a meta format of my own design (...the parsers for xml at that time were, in my opinion to slow to use on the client), so I used a more terse, but also non standard, home grown protocol. The generic applet received the response and then constructed the Swing gui panel, layout manager and all.

Is the basis of XFORMS the exchange of a genericized screen in form of xml that the client browser renders using a graphics package of it's choosing?

[Hans Bergsten]

Originally posted by Byron Estes:
How does JSF compare to XFORMS?

How are they similar and disimlar?

It's been over 3-4 years ago since I played with an idea to create a generic applet that could connect to a controller servlet which would send back metadata that described a screen with a layout, conceptual gui widgets, and data to populate each with...

I think I started with serializing the Swing based screen from the server to the client, which worked, but as you can imagine performed horribly.

I then switched to a meta format of my own design (...the parsers for xml at that time were, in my opinion to slow to use on the client), so I used a more terse, but also non standard, home grown protocol. The generic applet received the response and then constructed the Swing gui panel, layout manager and all.

Is the basis of XFORMS the exchange of a genericized screen in form of xml that the client browser renders using a graphics package of it's choosing?

I've studied XForms just briefly, so don't take my comments too seriously; I may very well be wrong.

XForms defines XML elements representing user interface widgets, pretty much the same as regular HTML form control elements, but it also defines a set of elements for binding the widgets to XML model data, perform validation, and an elaborate client-side event model. The end result is that with XForms, a lot of what's done with scripting in an HTML browser can be done declaratively in an XForms browser.

JSF is a server-side component technology, defining components that can be rendered as any type of markup elements (or even binary data). This means that JSF components can render XForms widget elements for an XForms browser. To do so, however, required a custom JSF renderkit because the only renderkit defined by the JSF 1.0 specification renders HTML elements.

Rendering is only one half of the problem, though. An application must also deal with input. With XForms, most (if not all) validation and simple user interface event handling (e.g., update a selection list based on a selection in another list) can be done by the browser without contacting the server, but eventually, even an XForm is submitted to a server. It seems like XForms can send the form data either as XML or as regular HTTP POST or GET data, so it should be fairly simple for JSF components to pick it up from the request.

This is all theory, though, based on a quick read-through of the XForms spec. How well it works in practice is a completely different story, but it would be interesting to try (if I ever find the time). One big obstacle is that none of the popular browsers support XForms out-of-the-box yet, so the user would have to install a browser plug-in or a separate XForms browser to use the application.

[Byron Estes]

Thanks Hans. It sounds very similar to what I designed and created as a prototype (...at least conceptually). One of the issues I struggled with in the protoype I was creating was how to deal with event processing within this generic interface applet. I think I'll have to take a look at it just to see how they dealt with similar issues. The whole process of prototyping this was a lark while I was preparing for by next consulting assignment which was the creating of a Account Access and Trading Framework to support Wireless Trading for a large online brokerage firm.

Have a great weekend.