W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

RE: XMLHttpRequest object suggestion

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Tue, 18 Apr 2006 10:38:25 +0100
To: <public-webapi@w3.org>
Message-ID: <007501c662cb$d8e07670$7e01a8c0@Jan>


> The solution works out extremely well when combined with the 
> setRequestHeader method. By setting a request header with 
> some specific value (Rails has started using the 
> "http-accept" header, I've been using a custom header), the 
> back-end can be told that a given request is an XHR request 
> rather than a regular page request, which allows it to return 
> just the data the calling script needs. WIthout the header, 
> it can return (or redirect to) the appropriate content as a 
> fully-formed HTML document. So when retrieving that URI via 
> either bookmark or back-button, the web server would know the 
> correct content to send based on the presence or absence of a 
> given value for a given HTTP header.

This is interesting stuff, but surely it's not a great idea to mix the data
and view in that way? Shouldn't there be one URI for the form and another
for the data? Interacting directly with the data could be done using XHR,
XForms, another server, a C++ or Java application, and so on. You are right
that the HTML form as fallback is a good idea, but it should simply be a
layer on top of the data URIs and not be using the same URIs. (If nothing
else the workflow could well be different.)



Mark Birbeck
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
Received on Tuesday, 18 April 2006 09:39:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC