It might look something like this:
postJSONDoc = function (url, postVars) {
var req = getXMLHttpRequest();
req.open("POST", url, true);
req.setRequestHeader("Content-type", "application/x-www-form-
urlencoded");
var data = queryString(postVars);
var d = sendXMLHttpRequest(req, data);
return d.addCallback(evalJSONRequest);
}
(Credit goes to Bob for writing it some time ago, I've used it
extensively on Tagalag.)
On Dec 7, 2005, at 11:14 AM, Bob Ippolito wrote:
On Dec 6, 2005, at 6:58 PM, Peter Hansen wrote:
Bob Ippolito wrote:
On Dec 6, 2005, at 6:20 PM, Peter Hansen wrote:
Bob Ippolito wrote:
http://en.wikipedia.org/wiki/
XMLHttpRequest#Microsoft_Internet_Explorer_Cache_issues
From the sounds of that, using POST instead of GET would avoid
the issue. It appears MochiKit.Async uses GET to do its work.
What would be the downside of using POST instead?
That sounds absolutely terrible.
At least adding some random stuff to the URL doesn't change the
semantics, but it's not typically that hard to add a header or
two on the server side to remove the need for that.
As someone who is using AJAX to access only his own servers (i.e.
I'm in control of both sides) I don't fully understand why it
would be absolutely terrible. From my point of view, POST vs. GET
is a total wash. My server code generally doesn't know which was
used (for forms, anyway... am I off-base in the world of AJAX
services?).
It's just semantics. POST requests are for posting data, and
loadJSONDoc doesn't do that.
Since you control both sides, you can issue proper cache headers,
or a URL based workaround.
I assume there are services where you *must* access it using only
GET. And, since MochiKit doesn't use POST even as an option, I
also assume there are no useful AJAX services which require a
POST. And since there are limits on the size of GET URLs in many
places (as I recall) I further assume nobody is concerned about
being force to use GET.
There are plenty of useful AJAX services which require a POST, but
loadJSONDoc and doSimpleXMLHttpRequest are only designed for simple
idempotent operations. As you may have noticed, most of MochiKit
is currently focused on just making JavaScript less painful, not
facilitating domain specific things.
There are several reasons that MochiKit currently doesn't have
baked-in support for anything but very simple GET
- That's all we (as in the sponsors/developers of MochiKit) need
right now
- The support for anything but GET and POST is poor cross-browser
(this is largely Safari's fault)
- There are at least three common ways to send POST data (url
encoded, JSON, and XML)
- It's often the case that you would also like to set custom
headers when doing something other than GET
MochiKit does support all of these rather well, but there simply
isn't a one-liner. We haven't come up with a good one-liner that's
generic enough to make it into MochiKit for the above reasons.
Here's how you do Anything But Simple GET:
1. getXMLHttpRequest() to get yourself an XMLHttpRequest object
2. Give it a method and a URL
3. Set any custom headers you need
4. Serialize your content for the post (typically via serializeJSON
or queryString)
5. dispatch with sendXMLHttpRequest(req, theContent)
I'm definitely open for API ideas, but I have a feeling it's just
going to be something like:
aDeferred = dispatchXMLHttpRequest({
method: "POST",
url: "...",
headers: [
["Content-Type", "text/x-json"]
],
content: serializeJSON(...)
}).addCallback(evalJSONRequest)
I'm just not sure it's worth bothering with that, because it seems
almost harder to deal with than a plain old XMLHttpRequest object.
-bob
