W3C home > Mailing lists > Public > www-forms@w3.org > October 2005

Re: AJAX vs. Xforms

From: Joern Turner <joern.turner@web.de>
Date: Tue, 25 Oct 2005 22:54:00 +0200
Message-ID: <435E9B68.6030401@web.de>
To: Erik Bruchez <erik@bruchez.org>
CC: www-forms@w3.org


Erik Bruchez wrote:
> 
> Rafael Benito wrote:
> 
>  > AJAX (Asynchronous JavaScript and XML) architectures are attracting
>  > a lot of attention from the Web developer community. Some features,
>  > like requesting to a server a piece of XML to update the UI without
>  > refreshing the whole browser window, that make AJAX to be gaining
>  > recognition, are also present in the Xforms Recommendation. However,
>  > it seems that Xforms adoption is evolving at a much lower rate than
>  > AJAX. I wonder for the reasons that are causing this to happen and
>  > what the Xforms community should be doing to more strongly push
>  > Xforms into the web development arena.
>  >
>  > Any ideas or comments on this issue?
> 
> Rafael,
> 
> Thanks for asking this question, as it is extremely relevant.
> 
> I respectfully and partially disagree with Jason's reply that Ajax and
> XForms are totally different beasts. Yes, of course, they are
> different in many ways. But I believe what is important is what people
> are actually trying to do with Ajax, namely provide interfaces which:
> 
> 1. Are snappier, by avoiding full page reloads and using Javascript to
>    update the current page (by updating the DOM). Functions performed
>    include: handling repeating items, showing and hiding parts of a
>    page, cool widgets, doing live validation, etc.
> 
> 2. Can communicate in the background with a server by exchanging XML,
>    therefore persisting client data, retrieving off-client data, etc.
> 
> XForms provides both #1 and #2:
> 
> 1. Especially with a full client-side OR an Ajax-based hybrid
>    client-server implementation, you clearly get snappier interfaces
>    which can also handle repeating items, showing and hiding parts of
>    the page, validation, etc. The "cool widgets" part is not mandated
>    by XForms, but such widgets can be provided by an XForms
>    implementation.
> 
> 2. Using XForms submissions with replace="instance", you achieve
>    calling XML services from your XForms page, which is just an
>    excellent high-level abstraction of the XmlHttpRequest object used
>    by most people today to do Ajax.
> 
> So in my opinion, it is fair to say that both the Ajax technique and
> XForms have shared end goals. In fact, you can see an Ajax-based
> XForms implementation like Orbeon PresentationServer's new XForms
> engine (currently in beta, and I remind you that it is open source!)
> as a high-level platform to do Ajax. And this is extraordinarily
> powerful, because Ajax is plain hard: you have to choose a toolkit,
> probably become a master of Javascript and DOM, etc. Instead, you
> could learn XForms, which is higher-level, declarative, and in the end
> more productive for the developer.
I agree with you both Jason and Eric ;)

It simply depends on your viewpoint. But there are differences which 
should be maybe pointed out to push all these discussions about 'AJAX 
versus XFORMS' forward to a more constructive level and see what they 
can profit from each other (sorry for repeating you here, Eric).

Jason is IMO right to say that they are very different in one way. AJAX 
concentrates on the 'friendlier interface' and improved interactivity 
alone and does not provide a complete architecture for handling user 
dialogs as XForms does. Even if some more advanced AJAX samples directly 
connect datasources on the backend and do some automatic updating they 
do so in a completely custom (and non-standard) way. In that respect 
AJAX is more a technique than a technology.

XForms on the other hand provides a clear model with separation of 
model, instance and UI in a MVC fashion, provides a clear processing 
model that guarantees consistency, an advanced dependency tracking and 
calculation model, nearly endless validation capability, strong 
data-typing, an event-model and an abstract UI definition. - well, sorry 
if i left out details but isn't that a bit more than simple AJAX has to 
offer?

Even if there are similarities in goals from an end users perspective 
AJAX and XForms are very different from an architectural or developers 
view. It's my personal belief that AJAX and XForms go very well together 
in these 'hybrid' implementations as Eric called them and can profit 
from each other in large dimensions. AJAX and XForms integrated would 
free the page developer from lots of custom script coding *and* get all 
the advantages of XForms processing while server-side XForms processors 
will be able to become much more accessible, friendly and interactive. - 
And all this by using a standard webbrowser without any installations. A 
bright perspective for server-side or hybrid XForms.

> 
> As Mark said, it is up to us in the XForms community to evangelize and
> tell people that XForms is a reality today, that it does much of what
> Ajax does, and that it is likely to be much more productive than bare
> metal Ajax. We should also not neglect the "cool" factor: we should
> work on telling people that XForms is really cool for their web apps,
> not just a boring tool for enterprise data entry.
Plain agree. More and more elaborated samples are needed and they also 
shouldn't leave the 'coolness factor' aside to compete in users eye with 
some of todays' AJAX samples but also emphasize the specific strength of 
XForms.

At Chibacon we also currently work on our own AJAX interface to our 
XForms processor. A demo will be made publish during November and 
hopefully show some non-trivial examples and we'll put some extra effort 
in explanations of features. We hope we can show a complete real-world, 
AJAX-enabled and non-trivial XForms 'application' for configuring 
network appliances.

just my 0.02 

Joern
> 
> My personal opinion is that yes, the WG is going way too slowly, which
> is unfortunately typical of much at W3C. But the 1.0 spec has been out
> for two years now, and what developers really need is not a spec, but
> good implementations which are as interoperable as possible, and good
> examples. Several implementations are already out there or coming
> soon. XForms support in Mozilla is coming up. More implementations
> will create demand for an improved and richer XForms
> specification. But implementations and good examples are essential.
> 
> Based on a recent survey, many people code Ajax by hand and do not yet
> use libraries much, see:
> 
> http://www.surveymonkey.com/DisplaySummary.asp?SID=1427046&U=142704624114
> 
> The bottom line is that consolidation in the Ajax world has not
> happened at all, so XForms has an excellent opportunity. In short I
> think that the future of XForms is going to be bright if the current
> XForms community plays well.
> 
> -Erik
> 
> PS: I refer you to this email for information about OPS:
> 
> http://lists.xml.org/archives/xml-dev/200508/msg00231.html
> 
> 
Received on Tuesday, 25 October 2005 20:55:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:02 GMT