Opened 11 years ago

Closed 3 years ago

#6526 closed enhancement (wontfix) support for JSONP with static callback

Reported by: kriszyp Owned by: Bryan Forbes
Priority: high Milestone: 1.11
Component: IO Version: 1.1.0
Keywords: Cc:
Blocked By: Blocking:


With static resources that may be requested by JSONP, it is necessary to use a static callback. This patch adds support to for requesting resources with a static callback (url is the callback name). See:

Attachments (1)

staticCallback.diff (1.8 KB) - added by kriszyp 11 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 11 years ago by alex

Owner: changed from James Burke to alex
Status: newassigned

comment:2 Changed 11 years ago by alex

hey Kris:

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


  • 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 ""

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

comment:3 Changed 11 years ago by 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 If you choose to use an url name, then you can manage that outside of

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.

comment:4 Changed 11 years ago by 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?

Changed 11 years ago by kriszyp

Attachment: staticCallback.diff added


comment:5 Changed 11 years ago by guest

James here again: I guess I am not sure why 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,[args.staticCallback] = ...), but I do not think 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.

comment:6 Changed 11 years ago by 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.

comment:7 Changed 11 years ago by Kris Zyp

Milestone: 1.2future

comment:8 Changed 8 years ago by Chris Mitchell

Owner: changed from alex to dylan

please review/triage

comment:9 Changed 8 years ago by dylan

Owner: changed from dylan to kriszyp
Status: assignednew

Kris, does this one still matter?

comment:10 Changed 8 years ago by bill

Owner: changed from kriszyp to Kris Zyp

comment:11 Changed 7 years ago by bill

Owner: changed from Kris Zyp to Bryan Forbes

Bulk change to reassign IO tickets to Bryan, since he is working on new dojo/request module. Some of these tickets should probably be closed as already fixed, invalid, or wontfix.

comment:12 Changed 6 years ago by dylan

Milestone: future1.9

Bryan, is this relevant with dojo/request?

comment:13 Changed 6 years ago by Kris Zyp

This may be possible by simply using a require() call now (perhaps with cache busting if necessary?)?

comment:14 Changed 6 years ago by bill

Milestone: 1.92.0

Since we released the beta for 1.9, presumably this enhancement should be bumped to 2.0.

comment:15 Changed 3 years ago by dylan

Milestone: 2.01.11
Resolution: wontfix
Status: newclosed

Does not seem relevant any longer. Can address for Dojo 2 if it's still an issue.

Note: See TracTickets for help on using tickets.