RE: Ajax revised

Art wrote:
> I have CC'ed the Web API WG's Public Mail List (archive 
> available at [5]); there is no need to cross-post to the 
> appformats mail list in follow-ups.

Here is a follow-up email that I had already posted to the formats list
before Art moved the thread.

Regards,

Mark


--- STARTS ---

Hi Maxim,
 
Excellent observations, but all of what you describe is already possible.

> Since all browsers are implementing XmlHTTPRequest object anyway, 
> wouldn't it be great to somehow describe this interaction with HTTP 
> server without custom client code, but, instead, with some XML 
> language? This will make web clients and users less vulnerable (no 
> custom code), so there will be less security issues.

Agreed, and XForms submission describes *everything* that an XHR does, and
more, by providing a layer of abstraction (see [1] for examples and a
discussion of this).


> The interaction can go like this:
> 1. Some event occurs -- mouse click, mouse move etc. Browser looks 
> through the table of events, and if event is handled, asynchronously 
> submits respective form and continues it's work.

A clear eventing architecture is already defined, DOM 2 Events [2], and the
XML version of it, XML Events [3].


> 2. Browser receives responce to some event. First, it looks at the 
> type of responce: whether it is "change" responce, which describes 
> some changes to the page, or "complete" responce.
> If the responce is of type "complete", browser renders new page (i.e. 
> it works old way).

That's the default behaviour in XForms submission--it works much like an
HTML form and replaces the 'current' document.


> Now, the interesting part is "change" responce. If browser receives 
> this kind of responce, it just renders received changes to the page.

Actually XForms is less HTML-centric than currently used Ajax techniques, so
it can do this in a much more powerful way.

If the default behaviour of replacing the entire page is overridden, then
the data received is placed into an 'instance' (an XML data model), and from
there it can be used in form controls. The current (scripted) techniques for
updating require you to change part of the UI, and so keep track of which
bits of the UI do what. In XForms you just change the *data* and let the
processor update any controls bound to nodes in that data, regardless of
where they are and how many of them there are.


> So browser sees, that this responce is a responce for event "register" 
> (somewhere in the header maybe) and looks for the slot for this event 
> in document. Than applies XSLT transformations, as if <slot...> 
> element is the root element

As far as I can tell, that's not far off how InfoPath works--using XSLT to
dynamically recreate parts of the document. It's a smart idea, but I believe
that the XForms model is superior (especially when combined with XBL). In
passing, I'd guess that Microsoft think there are better ways to do this
than doing a straight insertion from XSLT, since XAML doesn't use the
InfoPath/XSLT-style approach, and instead binds controls to data, like
XForms.


> First thing we need is some language for event-table specification.

See above...XML Events [3].


I think your comments are timely. I've seen a number of discussions about
the places where Ajax doesn't quite do enough, ranging from accessibility,
unit testing, managing script, lack of standard libraries, and so on. But I
think that the concept of 'Ajax' is such a great way to capture the idea of
rich, responsive web applications, and everyone knows what it means.

So I'd suggest that XForms should be seen as an Ajax Application language--a
perfect way to build web apps with all the features you would expect. (And
if we need to describe the 'browser-stack' of XHR, JavaScript, etc., perhaps
we should say 'AJAX'.)

Regards,

Mark

[1] The Submission Pattern,
<http://www.xforms-wiki.com/bin/view/Main/PatternSubmission>
[2] DOM Level 2 Events, <http://www.w3.org/TR/DOM-Level-2-Events/>
[3] XML Events, <http://www.w3.org/TR/xml-events/>


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Tuesday, 31 January 2006 12:58:03 UTC