POST requests and XMLHttpRequest

[Yaakov Nemoy]

Hi List,

I'm looking through the docs, and I'm not seeing much sophistication
to manipulating the actual request. I'm working on an app using lots
of forms, so using POST is pretty critical. Short of touching the
XMLHttpRequests myself (ie, throwing a bit of code ripped off another
framework) is there an official way to set this in Mochikit?

Yaakov

[koorb]

I would love to be able to do this too!

[Bob Ippolito]

No, there is not a built-in function for doing POST.

http://groups.google.com/group/mochikit/search?group=mochikit&q=post

-bob

[Yaakov Nemoy]

after reading that, i think the argument is just silly. at least 90%
of the forms i'm working on are going to just use querystrings to send
their data, and basically do something very similar just setting a
form method to 'post' in html. I'm sure someone wants to do something
fancier, but the code below isn't
called FancyPostXMLHttpRequest. Someone else can write that. So here
is some untested code:

doSimplePostXMLHttpRequest: function (url/*, ...*/) {
var self = MochiKit.Async;
var req = self.getXMLHttpRequest();
if (arguments.length > 1) {
var m = MochiKit.Base;
var qs = m.queryString.apply(null, m.extend(null, arguments, 1));
}
req.open("POST", url, true);
//taken from prototype, note that we can't use a hash map here, as
//we can't have hyphen in the property name
var requestHeaders =
['X-Requested-With', 'XMLHttpRequest',
'X-Prototype-Version', Prototype.Version,
'Accept', 'text/javascript, text/html, application/xml, text/xml, */*',
'Content-type', 'application/x-www-form-urlencoded'];
/* Force "Connection: close" for Mozilla browsers to work around
* a bug where XMLHttpReqeuest sends an incorrect Content-length
* header. See Mozilla Bugzilla #246651.
*/
if (req.overrideMimeType)
requestHeaders.push('Connection', 'close');
for (var i = 0; i < requestHeaders.length; i += 2)
req.setRequestHeader(requestHeaders[i], requestHeaders[i+1]);

return self.sendXMLHttpRequest(req)

},

I don't see a point of asking, how many ways can the developer scratch
his testicles by doing the macarena, so I wrote something i can use,
and test as soon as I figure out why firefox want's to play nice with
something else. If anyone has a ready test available, let me know it
it works :)

Cheers,
Yaakov

[Yaakov Nemoy]

Hi List,

On 7/5/06, Yaakov Nemoy <loupgar...@gmail.com> wrote:
> fancier, but the code below isn't
> called FancyPostXMLHttpRequest. Someone else can write that. So here
> is some untested code:
>

> I don't see a point of asking, how many ways can the developer scratch
> his testicles by doing the macarena, so I wrote something i can use,

So here is the code, working in JDeveloper 1013 and works in Firefox and IE.
To use it, it's exactly the same as Async.doSimpleXMLHttpRequest(),
and to integrate it into your MochiKit setup, just add it right after
the same method. Without further ado:

doSimplePostXMLHttpRequest: function (url/*, ...*/) {
var self = MochiKit.Async;
var req = self.getXMLHttpRequest();
if (arguments.length > 1) {
var m = MochiKit.Base;
var qs = m.queryString.apply(null, m.extend(null, arguments, 1));
}
req.open("POST", url, true);

//taken from prototype, pretty much verbatim

var requestHeaders =
['X-Requested-With', 'XMLHttpRequest',

'X-MochiKit-Version', MochiKit.Async.VERSION,

'Accept', 'text/javascript, text/html, application/xml, text/xml, */*',
'Content-type', 'application/x-www-form-urlencoded'];
/* Force "Connection: close" for Mozilla browsers to work around
* a bug where XMLHttpReqeuest sends an incorrect Content-length
* header. See Mozilla Bugzilla #246651.
*/
if (req.overrideMimeType) {
requestHeaders.push('Connection', 'close');
}
for (var i = 0; i < requestHeaders.length; i += 2) {
req.setRequestHeader(requestHeaders[i],
requestHeaders[i+1]);
}

return self.sendXMLHttpRequest(req, qs);

},

If it get's integrated into the next release, let me know :).

[John Wang]

On 7/6/06, Yaakov Nemoy <loupgar...@gmail.com> wrote:

        //taken from prototype, pretty much verbatim
            var requestHeaders =
                        ['X-Requested-With', 'XMLHttpRequest',
                         'X-MochiKit-Version', MochiKit.Async.VERSION,

Instead of propagating custom headers like X-Prototype-Version (and X-MochiKit-Version), I'd prefer more standardized approach like what is done with User-Agent already:

'X-XMLHttpRequest-User-Agent', 'MochiKit/' + MochiKit.Async.VERSION

It would be great if it was something all the libraries could agree on. Eventually this will probably be standardized anyway and in the meanwhile, it would make determining the library version easier on the server-side.

I wrote about this on my blog here:

http://www.dev411.com/blog/2006/06/30/should-there-be-a-xmlhttprequest-user-agent

Any thoughts?

John

[Yaakov Nemoy]

Yes,

i have a few thoughts.

On 7/6/06, John Wang <john...@gmail.com> wrote:
> Instead of propagating custom headers like X-Prototype-Version (and
> X-MochiKit-Version), I'd prefer more standardized approach like what is done
> with User-Agent already:

Yes, standards are good, cause we seem to have so many of them.

> 'X-XMLHttpRequest-User-Agent', 'MochiKit/' + MochiKit.Async.VERSION
> It would be great if it was something all the libraries could agree on.
> Eventually this will probably be standardized anyway and in the meanwhile,
> it would make determining the library version easier on the server-side.

I think it begs the question though, why does the server need to
differentiate between different Ajax libraries? In fact, the only
thing that we should differentiate is whether it's an XMLHttpRequest
or not, and even that might not be appropriate. If one AJAX library
decides to do something different, or requires specialized output from
the server, and then we allow the server to differentiate between
libaries via request headers, there's less incentive for a programmer
to keep his AJAX library in line with others.

I think ideally what we want is the data form the server to be AJAX
Library agnostic. Otherwise you have the same situation, where a
server can differentiate between rendering engines, and in theory give
HTML back designed around that browser. (Even though that doesn't
happen that often)

Still, It's a nice thought, if you have an environment where several
different web apps are utilizing the same server for the same
information, it would be nice for the server to do statistics, or
anything else. Probably some sort of rich interaction with the
client.

Your suggestion does make sense, so make that change if you want,
especially if that gets ported into MochiKit. Better to have it
standardized. I can already tell someone will try to do something
differently, and we're gonna have to suffer with the idiot decision.
<cough>IE</cough>

Yaakov

[John Wang]

On 7/6/06, Yaakov Nemoy <loupgar...@gmail.com> wrote:

I think it begs the question though, why does the server need to
differentiate between different Ajax libraries?  In fact, the only
thing that we should differentiate is whether it's an XMLHttpRequest
or not, and even that might not be appropriate.

I agree this is best in theory and that's what I wanted before I started seeing libraries doing different things.
 

Your suggestion does make sense, so make that change if you want,
especially if that gets ported into MochiKit.  Better to have it
standardized.  I can already tell someone will try to do something
differently, and we're gonna have to suffer with the idiot decision.

I talked to Alex Russell of Dojo about this and he agreed this would be useful and should be standardized. We discussed using a shorter name and he came up with X-Ajax-Engine . Although neither of us are crazy about using 'Ajax' in the name it is short and fairly unambiguious. He also mentioned he could bring this up at the OpenAjax Alliance.

What does everyone think?

--
John Wang
Blog: http://www.dev411.com/blog/

[Bob Ippolito]

That sounds reasonable to me. The names aren't that important, all it needs is buy-in from developers making stuff.

Hell, the HTTP spec misspells Referer [sic], using ajax in the name definitely isn't any worse than that :)

-bob

[BKH...@gmail.com]

Thank you very much. I will put this in a local include of its own
until it shows up in MochiKit. I think a lot of the user community
will be like me and need this. More sophisticated interfaces can come
later after the brilliant ideas come to people.