This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Struts and the fly likes JSF versus XFORMS Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "JSF versus XFORMS" Watch "JSF versus XFORMS" New topic
Author

JSF versus XFORMS

Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
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?


Byron Estes<br />Sun Certified Enterprise Architect<br />Senior Consulant<br />Blackwell Consulting Services<br />Chicago, IL<br /><a href="http://www.bcsinc.com" target="_blank" rel="nofollow">www.bcsinc.com</a>
Hans Bergsten
Author
Ranch Hand

Joined: Dec 01, 2003
Posts: 106
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.


Hans Bergsten, hans@gefionsoftware.com<br />Author of O'Reilly's<br />- JavaServer Pages,<br />- JavaServer Faces<br /><a href="http://www.hansbergsten.com/" target="_blank" rel="nofollow">http://www.hansbergsten.com/</a>
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JSF versus XFORMS
 
Similar Threads
Image display in layout manager
Struts JSF Design Flaw (who is to blame)
GUI and Processing, how to seperate?
I dont think I may use AWT.
GUI client talk to servlet