Views
XForms Or Ajax?
From PicoForms
Contents |
[edit] Introduction
A lot of the questions we get asked at PicoForms revolve around comparison between Ajax and XForms. People can see after the most cursory glance that Ajax and XForms both include the essential 'x' in their names, and that they have something to do with data-driven Web applications. Beyond that things tend to get a bit woolly.
So, which is best? When should you use one rather than the other? Well, let's take a (brief, relatively non-technical and high level) look and see what we think.
[edit] So Ajax is?
An acronym: Asynchronous JavaScript and XML. At its heart Ajax appears to be a way of exploiting Javascript and DHTML (Dynamic HTML) to pass data in and out of a browser-hosted Web application without having to replace an entire HTML page every time data is exchanged with a server.
Really Ajax is about building sophisticated Web applications that are pleasant and attractive to use. Avoiding page refresh is just one, important aspect of achieving this aim. Good user interface design is also central to Ajax.
Developers have got used to being able to dip into an ever-growing bag of UI widgets to enhance the usability of their desktop app.s, and now the Web developer is able to use Ajax-based toolkits to do the same on the browser. Open source and commercial Ajax products include their own widget arsenals, each with their own mechanisms for invoking functionality built into lower-level Javascript libraries.
If you want to use Ajax you can deploy to any browser with good Javascript and DHTML support. You will need an add-on, but that is just a script library, and obviously you need to make sure you link the right script libraries to your application, as there is no Ajax standard and all the libraries are a bit different.
[edit] And XForms?
Unfortunately the name XForms isn't an acronym, though it is still very suggestive: the 'X' of XML and the 'forms' of, well, forms. XForms has very similar objectives to Ajax: it aims to allow developers to build sophisticated Web applications that are pleasant and attractive to use. It too can talk to a server without the need for a page refresh.
It does go a bit further by saying that a Web application doesn't necessarily sit in a conventional Web browser, so it is designed to support multiple device types (our processor is used on Web browsers, mobile phones and printers, for example).
For that, and other reasons, XForms doesn't really say a huge amount about specific UI widgets; there are a few generic types that are as useful whether you have a visual or an aural interface (for example), and some hints about presentation, and that is it. On the other hand, XForms says a great deal more about how to build an XML-oriented data model to which you bind your UI, and the eventing system that is used to synchronise model and view: the necessary plumbing of any Web application.
XForms certainly builds on the legacy of HTML, and can be embedded in XHTML, but it is akin to the Ajax toolkits with their own markup that must be interpreted by code libraries hosted in the conventional browser. And guess what, XForms can be implemented as Javascript libraries, just like Ajax (in fact even using Ajax), but more normally XForms processors are implemented as a plug-in or extension, rather like Flash.
Unlike Ajax, XForms is a standard (well, a W3C Recommendation anyway), and so you stand a good chance of being able to run the same XForm with different XForms processors with either no, or minimal changes.
[edit] Widgets
[edit] Ajax
If you look at pretty much any Web site for an Ajax product you will immediately be overwhelmed by the beauty, variety and sophistication of its widget library. There will be all manner of toolbars, panels, grids, trees, sliders, menus and whatnot. To the casual observer it appears that this is where the Ajax houses really put their effort, and why not, it is something the hard-pressed Web developer craves.
However, let's be boring and look a little under the skin of a simple widget. Say you want a form with an text input box in it. Well, there are a variety of ways you can get it, so here are a few examples:
With SmartClient you need the following markup:
<DynamicForm width="300">
<fields>
<field title="Item" type="text"/>
</fields>
</DynamicForm>
Using Dojo you use the much more familiar and backwardly compatible:
<FORM>
First Name:
<input type="text"
length="20"
name="first"
dojoType="dijit.form.TextBox"
trim="true" propercase="true" />
</FORM>
Another approach is to reuse existing HTML attributes such as class to indicate the widget to use.
Ajax libraries also let you build a UI programatically, this example coming from ActiveWidgets:
<script>
var obj = new AW.UI.Input;
obj.setControlText("Input");
obj.setControlImage("search");
document.write(obj);
</script>
Ajax libraries tend to offer quite fine-grained control of UI widget appearance and functionality such as data masking and validation. The developer has plenty of opportunity to tune their application to enhance look and feel and tweak performance. As I say, a lot of time and thought has gone into creating widgets that would look as good in a conventional desktop application as on a Web page.
[edit] XForms
Widget? XForms? You must be joking! Look at the Web Site of an XForms vendor (oh you are - sorry). Do you see a vast widget catalogue to salivate over? Of course you don't. You will see plenty about MVC architecture, about how easy it is to bind an XML instance to the UI, to include calculations without script.
You will see how little code you need to write, and how easy XForms applications are to maintain. But it may all look a little ordinary (no offence to other XForm processor vendors).
XForms has its generic form components: group, switch/case, repeat, trigger, input, secret, textarea, select1, select, range, upload and submit, and that's your lot.
Here is the XForms version of the input we looked at above:
<xf:input ref="name"> <xf:label>My Text box<xf:label> </xf:input>
Not so different, except that it is bound directly to a node in an XML document.
The XForms specification does suggest how things might be rendered, if you like, but nothing is mandated. The XForms UI is pretty much an abstract thing designed to reflect an author's intent in putting a control into an application, rather than what they want it to look like once it is there. You want a user to select one thing from a list? Use a select1. You want them to input something somehow? Give them an input; and so on.
Of course an input could be presented in many different ways - a textbox, a pause following a spoken question, a calendar widget, what ever you like, but unlike Ajax, the markup underneath will always be the same.
[edit] Data In, Data Out
[edit] Ajax
Most Ajax tutorials will somewhere include a fairly generic Javascript (for example) function to show how the XMLHttpRequest Object can be used to submit and fetch data, and how that data can be instantiated as an XML document, which can in turn be navigated and manipulated using the DOM.
Then there will be instructions on how to bind things like grids or trees to data sources.It is all standard, imperative coding: rather long-winded, with application logic often expressed as script, or widget properties, or both. But what people are getting used to by now, and at least it looks good.
Certainly most Ajax libraries seem to expect the author to want and need to control data flow, validation and manipulation at a pretty low level. Consequently Ajax tutorials do seem to include quite a lot of code that is required to manage quite mundane, oft repeated tasks.
[edit] XForms
XForms has its data model, of course. You declare XML instances, internal or external; you declare how they are submitted to servers; you replace them with what comes back. You bind as much or as little of the UI as often as you like to these instances, and the UI dutifully keeps itself in synch.
Declarative is a key word in the previous paragraph. Much of XForms' functionality is achieved by declaration, rather than by imperative code. Consequently it will often be brief and intelligible at first glance, especially to people who work with spreadsheets and/or XSLT.
If data structures repeat (lines in an order - that sort of thing), well, you just use an XForms repeat in the UI, and the UI dynamically creates and destroys itself as repeating items come and go. Again no script.
Once you have you model, your submissions, any calculations you might need, and have bound it to the UI, there isn't really much else to do. XForms encapsulates into its markup and processing model a lot of the housekeeping tasks that Ajax requires the user to write script to manage.
Consequently the code of an XForm can look a little bare, when compared to Ajax.
[edit] Some Conclusions
Broadly speaking it would seem that XForms and Ajax are just different takes on the same set of problems.
Ajax has risen out of the mess of Javascript that Web app.s have become as they try to do more and more. Its starting point is low-level control of the UI, and it really is just Javascript, CSS and DHTML. Consequently if there is some functionality that Ajax doesn't have, that you think it should have, well, so long as you can code it in Javascript, DHTML and CSS then you can build it, add it to a library, and bingo! Ajax can do it after all.
XForms is more of a step back, a deep breath, and attempt to apply to the Web some of the tried and trusted techniques that developers of "traditional" distributed and desktop applications take for granted. It gives the Web a scalable, manageable architecture for building Web app.s. XForms encapsulates a lot of the plumbing that all Web app.s need, and provides a standard framework to work within.
However, if XForms doesn't do something, it really doesn't do it until the spec. changes, whenever that may be. Also XForms holds itself aloof from the details of particular deployment needs. XForms isn't really enough on its own to make your application look good, as well as work well. There again, Ajax isn't really enough to make your application easy to maintain, robust, and all those other good but boring things that hurt if you don't get them right.
So what do we do? Neither Ajax or XForms is a complete answer. Rather they are different parts of a good answer. To give of their best XForms and Ajax really need to be combined. They are complementary technologies.
XForms manages the relationship between model, controller and view in a nice, safe, reliable and productive way. It provides a nice declarative, spreadsheet-like way for expressing your application logic. While Ajax allows you to customise and extend, with script and to create the right look and feel for particular deployment environments.
[edit] So What Do We Do Now?
Well, I don't know about you, but PicoForms is working on integration of Ajax widget sets with its soon to be released XForms processor for Microsoft Internet Explorer. Watch this space, as they say.
