- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Tue, 18 Apr 2006 10:38:25 +0100
- To: <public-webapi@w3.org>
Mark, > 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.) Regards, Mark 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, 18 April 2006 09:39:32 UTC