XForms – Lagging Implementations Point to Bigger Issue

XForms seem like such a good idea.  With declarative binding of form fields directly to XML document elements, you can implement an XML-centric XFormx/REST/XQuery (XRX) architecture and avoid a bunch of complex server-side code: no Javabeans needed to map HTML form fields to Java objects, and no object-relational mappings to persist the data.  Use some XSLT to create XForms from a schema, and you could eliminate most of the custom programming needed to collect, store, and display business information.
So why — nearly 10 years after the initial XForms recommendation — why aren’t XForms being used everywhere?  Our recent experience on a research project provides a clue.
First, XForm implementations are lagging.  There are arguably only a couple robust implementations on the market: the rest are little more than tinker toys that are extremely limited and fragile.  In addition, the implementations have enough extensions and different interpretations of the standard that code portability is non-existant, so you’re locked into a product.  This is a far cry from JSF, which has more than a dozen implementations that are more or less interchangeable.  The paucity of good implementations is an immediate problem for a development project, but it is really just a symptom of a deeper issue.
The real issue may be that the things that make XForms so great in theory make it hard to adopt in practice.  XForms provides relativly complete support for the model-view-controller (MVC) pattern, including a robust event model.  Cool, now you can do highly-interactive AJAXy things on the client.  But now the developer is working in a strange world of XForms event programming rather than Java or JavaScript.  Whoa…we’re going to discard all that experience and infrastructure?  And do all our control scripting in an XML dialect?  And what about a debugging environment?  The idea of client-side support for the MVC model sounds great, but when you get into you find it was the “MV” part that was exciting, and the “C” comes along like unwanted baggage.  But even the “M” part can be an issue.  Say you want to let users check of a bunch of items on a list for processing.  In a traditional form, it’s easy to provide a combined view of a perstent object with transient (checkbox) data.  But doing that in XForms either mucks up our business object with control data, or requires a second correlated object, which isn’t really supported by the standard XForm controls.  And what about paging a large list?  I could go on, but the point is that developers will have to find new ways and awkward workarounds for everyday features of all but the simplest forms.
The problem with this deeper issue is that it will be very slow to be resolved, if it is resolved at all.  If the only issue with XForms was in weak implementations, a new development project might be willing to bet on rapid improvements driven by high demand.  With deeper issues at play, I wouldn’t bet on it.
Posted in Blog Posts.

Leave a Reply

Your email address will not be published. Required fields are marked *