- From: Joern Turner <joern.turner@web.de>
- Date: Tue, 25 Oct 2005 22:54:00 +0200
- 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 UTC