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 meansTreat what you get in the server response as fresh form data.
Notice the close relationship toXML-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 formChoose 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.
