> Today I ran into something that caused me to look at my little bit of
> synchronous XMLHttpRequest again. So, I decided to look at putting
> something into MochiKit. I do think having an options hash is a good
> idea for the same reason that Python has keyword arguments. We'll have
> an exponentially growing number of functions without it, i think.
> Here's what I'm thinking:
> I'm envisioning decode having one option right now: "json". I'd
> imagine in the future it would be useful to be able to pass in a
> function as well (like an XML decoder, say). The JSON one is simple
> enough that just declaring the string "json" should be enough.
> Parameters would be a hash that would get encoded and sent properly
> for a GET or a POST, which would be a lot more convenient than
> stringing it up on the URL yourself.
I don't really see the benefit of a decode function (much less a
registry of string->function), that's really what addCallback is
for. The function suitable for JSON callbacks is simply
MochiKit.Async.evalJSONRequest. The reason things are what they are
is because the code for MochiBot deals only in JSON documents via GET
urls with nothing fancy required along the way. However, the
JavaScript code is simply asking for information, it never causes any
state change on the server. All of our state changing operations are
still traditional HTML form POST operations.
The rest of the idea I like though. Options objects are great if you
have more than two or three things you can specify and there is no
obvious order to default them in... MochiKit just doesn't currently
have much code in there yet where that makes sense (but this is
certainly a case where it does).
> If memory serves, this is pretty similar to what Prototype and Dojo
> offer (except Dojo envisions a world where you might be transporting
> packets by carrier pigeon rather than just HTTP like the rest of us
> :).
Yeah, there is definitely precedent for options objects in Dojo from
what I've seen.
> The trick with this is the return value: synchronous requests really
> only need the XMLHttpRequest object back, whereas async needs a
> Deferred. My inclination is for this function to always return a
> Deferred. If need be, there can be a single wrapper function for
> synchronous requests that very clearly returns the req object.
> I wanted to get your opinion on this before I actually write
> something.
Does a synchronous XMLHttpRequest end up calling onreadystatechange? If so, I guess async/sync can be the same function and both can
return a Deferred.
If not, then they should probably be separate functions (though they
will certainly share a common code path).
One thing I would love to see synchronous requests for is a
MochiKit.Logging observer to more or less replace alert() (i.e. works
even if the JavaScript code totally gets hosed or the browser crashes).
> > }
> I don't really see the benefit of a decode function (much less a
> registry of string->function), that's really what addCallback is
> for. The function suitable for JSON callbacks is simply
> MochiKit.Async.evalJSONRequest. The reason things are what they are
> is because the code for MochiBot deals only in JSON documents via GET
> urls with nothing fancy required along the way. However, the
> JavaScript code is simply asking for information, it never causes any
> state change on the server. All of our state changing operations are
> still traditional HTML form POST operations.
You're right, addCallback should be just fine. Let me make sure I'm
clear on usage:
d = doXMLHttpRequest(options...);
d.addCallback(evalJSONRequest)
d.addCallback(doMyFancyApplicationThing)
d.addErrback(somethingBadHappened)
doMyFancyApplicationThing will get called with the object that
resulted from the JSON eval.
> The rest of the idea I like though. Options objects are great if you
> have more than two or three things you can specify and there is no
> obvious order to default them in... MochiKit just doesn't currently
> have much code in there yet where that makes sense (but this is
> certainly a case where it does).
Yep. I gathered what your usage scenarios were like based on what
MochiKit had. I've already had to deal a little bit with the pain of
URL building in JavaScript, and I'd really like to see that logic
incorporated into a nice handy function that basically amounts to "get
my data from the server".
> > The trick with this is the return value: synchronous requests really
> > only need the XMLHttpRequest object back, whereas async needs a
> > Deferred. My inclination is for this function to always return a
> > Deferred. If need be, there can be a single wrapper function for
> > synchronous requests that very clearly returns the req object.
> > I wanted to get your opinion on this before I actually write
> > something.
> Does a synchronous XMLHttpRequest end up calling onreadystatechange?
> If so, I guess async/sync can be the same function and both can
> return a Deferred.
> If not, then they should probably be separate functions (though they
> will certainly share a common code path).
Synchronous XMLHttpRequest does not call onreadystatechange. It just
returns once the request is done. I'm not a fan of two distinctly
different possible return values for a function, so I agree that they
should be separate.
> One thing I would love to see synchronous requests for is a
> MochiKit.Logging observer to more or less replace alert() (i.e. works
> even if the JavaScript code totally gets hosed or the browser crashes).
That could be cool, I agree. Luckily for me, I haven't crashed the
browser with my JavaScript yet :)
>> I don't really see the benefit of a decode function (much less a
>> registry of string->function), that's really what addCallback is
>> for. The function suitable for JSON callbacks is simply
>> MochiKit.Async.evalJSONRequest. The reason things are what they are
>> is because the code for MochiBot deals only in JSON documents via GET
>> urls with nothing fancy required along the way. However, the
>> JavaScript code is simply asking for information, it never causes any
>> state change on the server. All of our state changing operations are
>> still traditional HTML form POST operations.
> You're right, addCallback should be just fine. Let me make sure I'm
> clear on usage:
> d = doXMLHttpRequest(options...);
> d.addCallback(evalJSONRequest)
> d.addCallback(doMyFancyApplicationThing)
> d.addErrback(somethingBadHappened)
> doMyFancyApplicationThing will get called with the object that
> resulted from the JSON eval.
Yeah, that's exactly right!
>> One thing I would love to see synchronous requests for is a
>> MochiKit.Logging observer to more or less replace alert() (i.e. works
>> even if the JavaScript code totally gets hosed or the browser
>> crashes).
> That could be cool, I agree. Luckily for me, I haven't crashed the
> browser with my JavaScript yet :)
Have you been doing any IE testing? :)
Actually, I've crashed Safari and Firefox too, but IE is the most
frequent loser :)
I'm thinking about doing an 0.70 release on Thursday, do you think
that doXMLHttpRequest is important enough to do before then? Do you
want to do it Kevin, or should I take a stab at it?
Here is the change list so far that's going into 0.70 (in reverse
chronological):
- sendXMLHttpRequest and functions that use it (loadJSONDoc, etc.) no
longer
ignore requests with status == 0, which seems to happen for cached
or local
requests
- Added sendXMLHttpRequest to MochiKit.Async.EXPORT, d'oh.
- Changed scrapeText API to return a string by default. This is API- breaking!
It was dumb to have the default return value be the form you
almost never
want. Sorry.
- Added special form to swapDOM(dest, src). If src is null, dest is
removed
(where previously you'd likely get a DOM exception).
- Added three new functions to MochiKit.Base for dealing with URL query
strings: urlEncode, queryString, parseQueryString
- MochiKit.DOM.createDOM will now use attr[k] = v for all browsers if
the name
starts with "on" (e.g. "onclick"). If v is a string, it will set
it to
new Function(v).
- Another workaround for Internet "worst browser ever" Explorer's
setAttribute
usage in MochiKit.DOM.createDOM (checked -> defaultChecked).
- Added UL, OL, LI convenience createDOM aliases to MochiKit.DOM
- Packing is now done by Dojo's custom Rhino interpreter, so it's
much smaller
now!
the new scrapeText function breaks API, so if anyone was using that
before you'll either have to remove the .join("") or add a second
true argument.
The changes log sits at doc/rst/MochiKit/VersionHistory.rst, which
should be in sync with any goings-on.
> I'm thinking about doing an 0.70 release on Thursday, do you think
> that doXMLHttpRequest is important enough to do before then? Do you
> want to do it Kevin, or should I take a stab at it?
It doesn't make much difference to me if it makes it into 0.70. The
next release is fine also, as far as I'm concerned. I'd imagine that
the number of people using synchronous XMLHttpRequest is pretty small.
I'm getting close to wrapping up my current bit of work, and then I'll
be putting some more work into MochiKit. I don't think I have anything
else in my immediate queue that requires MochiKit changes...
|
