XForms And AJAX Applications In Perspective

The following article by Kurt Cagle makes some excellent points that are worth summarizing here --- I highly recommend his article cited above, and his subsequent follow-ups that his article promises. His detailed write-up helps put Web developments of the last 6 years in perspective --- I'll summarize the salient bits below:

XForms Processing Model

When we set out to define the next generation of Web forms technology in early 2000, we had some very lofty goals which I believe we achieved very welll -- modulo the fact that our enthusiastic optimism at the time made us believe that we'd be done in 2 years. (Fact Of Life --- it's still happening). The primary underpinning of XForms is not the beloved XML angle-brackets, it's the processing model that does for structured XML what spread-sheets achieved for tabular data two decades ago.

XForms Submission

Everyone talks of XForms UI controls all the time, and depending on their perspective either praises it --- or as happens far too often --- mocks it for its abstract UI controls. Sometimes people even make it beyond this and get to talking of the XForms Model, and then fall into the tarpit of arguing over declarative vs imperative programming. The upshot of course is that they never get around to talking about the XForms Submission mechanism.

The XForms Submission mechanism was designed in early 2001 with the insight that the HTML model of replacing the entire page each time one did a client/server round-trip was suboptimal with respect to good user experience on the client. This is why XForms Submit allows you to say
<submission replace="instance">...</submission>
which means

Treat what you get in the server response as fresh form data.

Notice the close relationship to XML-HTTP --- this is not an accident. XForms Submission was invented right around the time XML-HTTP began showing up on the radar as a means to reduce angle-bracket client/server chatter that plagued older HTML Forms.

But getting XML Data from the server is only one half of the Web application story --- to be useful, the retrieved data needs to be made tangible to the user. In conjunction with the afore-mentioned XForms Processing Model, the above is sufficient to account for the several pages of application-specific JavaScript that each AJAX application requires for moving the data from the XML response into the UI tree and back.

Model Constraints

Kurt gives an excellent overview of how the XForms Model and the encapsulated constraints help the developer progressively evolve the model. He also points out how this is typically more difficult to do when the entire application is implemented as a program. I'd like to add the following in the hopes of finally laying the declarative vs imperative debate to rest --- at least in the context of XForms.

In fact, all declarative vs imperative debates are at best pointless religious debates, in practice, one finds that combining the two approaches as appropriate often leads to the best implementations. In this context, XForms declarative constraints reflect a refactoring of those parts of a Web application that need to change often from those aspects of Web interaction that follow a common design pattern. Thus, once the model constraints and the inter-dependencies among data items in the model have been refactored, what emerges is the XForms Processing Model --- which by the way is implemented in imperative languages ranging from C/C++ to JavaScript.

The net effect is to move the coding of the complex bits into the browser e.g., the Firefox XForms plugin or the various IE extensions, and free the Web developer to focus on key aspects of the application at hand. Now, it's probably understandable that browser vendors cried foul in the early days of XForms --- after all, now the browser had to do more; however, if you look back at the history of computing, compiler writers always cry foul when you raise the level of abstraction present in your language. The encouraging thing --- both from the history of computing, as well as from the last two years of XForms adoption is that over time the interests of the application developer moves the compiler (in this case browser) implementor to build support for the higher-level abstraction --- the former negative of I need to do more from the browser turns into a positive of the form Choose my browser platform because I do more for you the developer!.

Consistent Eventing

Web applications on the client come to life thanks to client-side eventing. Developing AJAX applications for legacy browsers is time-consuming because of inconsistent eventing --- though some of this pain is assuaged by using appropriate cross-browser JavaScript libraries whose implementors have bravely shouldered that pain --- similar to the compiler/browser developer taking the hit of implementing support for higher-level abstractions. When we developed XForms 1.0, we made a very concious decision that:

• We would require full DOM2 Events support --- including event bubbling and capture.
• To keep the language extensible, we used XML Events to author event binding.

Together, the above leads to a robust interaction model with the necessary flexibility of allowing application developers the needed extension points to hook custom behavior. It does suffer from the fact that browsers need to implement a consistent eventing model; once again, notice that this apparent negative is saying nothing more than

Over time, browsers will absorb the functionality present in cross-browser eventing libraries, thereby obviating the need for an application to download a library that provides this abstraction layer.

XForms Via AJAX

The primary attraction for using AJAX is that it is easy to deploy in an environment where legacy browsers co-exist with next-generation Web technologies. It is crucial here to realize that AJAX is an excellent deployment technology --- even though it may not be the best choice when it comes to authoring an application. In completing this circle, it is encouraging to see many XForms implementations beginning to process XForms markup on the server to deliver an AJAX deployment of the application to legacy browsers --- thereby reflecting yet another design point of XForms 1.0 --- namely --- the XForms Processing Model must be implementable in any of the following forms:

• Entirely on the client
• Entirely on the server
• Partially split between client and server

And still be able to deliver a consistent user experience. Here, consistency of user experience is intended to be more than screen-deep; consistency means that the user gets the same answer independent of the runtime deployment environment that is used to access the application.