- 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.
