dojo.io.script support for JSONP with static callback

[kriszyp]

With static resources that may be requested by JSONP, it is necessary to use a static callback. This patch adds support to dojo.io.script for requesting resources with a static callback (url is the callback name). See: http://www.json.com/2008/04/01/static-json-with-callback/

[alex]

hey Kris:

there are some issues with the code formatting. Please see the Dojo Style guide:

http://dojotoolkit.org/developer/StyleGuide

Namely:

• ensure that you are using real tabs and not spaces
• else statements go on the same line as the curly brace that preceeds it, without spaces
• instead of "window", please use "dojo.global"

otherwise the patch looks good and I'll be happy to merge it when the style issues are fixed.

[guest]

This is James Burke (having trouble with my trac login): I have a reservation about the patch:

It assumes if you want a static callback it has to be an URL. I would rather see more generic static callback support where the staticCallback is the name of the function to be attached to to dojo.global. If you choose to use an url name, then you can manage that outside of dojo.io.script.

This code will only support handling one callback at a time. This is probably a limitation of having a static callback, but you are likely going to get some weird behavior in Firefox if you have a periodic polling and get a timeout: even if we remove the script tag, FF will still execute a delayed response, so the callback will likely be triggered on the Deferred that did not match the original request. Probably nothing we can do about that given the FF bug (I filed a bug with mozilla on it) and the nature of having a static callback. So not a problem with the patch, but indicating an issue with having static callbacks.

[kriszyp]

James, allowing for explicitly setting the callback name seems like a good idea. What if we allowed args.staticCallback to be a string to indicate the callback name, or true to indicate that it will be automatically determined by the URL? I was working on this as a possible solution for loading cross-domain SMDs, where we can just provide a URL and get the SMD data. We could move the URL->callback logic to dojo.rpc.Service, if you don't want it in script.js.

As far as multiple callbacks, I will try add that functionality later. In the meantime would it be safe to have ioArgs.canDelete stay false?

Alex, I fixed the other issues, but where do you see spaces?

[kriszyp]

Patch

[guest]

James here again: I guess I am not sure why dojo.io.script has to have the URL building logic. And looking at the URL building, it uses window.location as part of the location, so the only URLs it constructs are back to the same domain as the HTML page? I am not sure that will help in xdomain cases?

I like supporting URLs as the function name (by using something like, dojo.global[args.staticCallback] = ...), but I do not think dojo.io.script should be in the business of constructing the URL string. It seems to be assuming too much about URL construction.

I will have to look at the side effects of ioArgs.canDelete when I can get better access to the source code.

[kriszyp]

This is just so that it will also work locally (in test cases for example). The target file has to a static string (it's full URL). The URL building does nothing in cross-domain requests, but when used locally it makes the same URL string as would be expected by cross-domain request. That could certainly be removed though, the local use case is not very important.