Cappuccino Cappuccino

Comments and changes to this ticket

• 

  Ross Boucher September 8th, 2008 @ 08:34 PM

  Jeremy,

  What you're saying is, some APIs always call

  
  myFixedCallback({someObject...});
  

  Seems like every JSONP API I've used has the feature to specify a callback function name. More importantly, it's required for a generic JSONP system to work I think. Otherwise, you've got a global shared callback and you can't have multiple simultaneous requests.

  Of course, the way this is currently implemented, you could still implement said global callback in your own code. By passing an empty (or garbage) parameter to "callback:", you can still fire the event, and implement the global callback function in JavaScript to receive the response.

  Thoughts?

• 

  Ross Boucher September 8th, 2008 @ 08:50 PM

  • State changed from “new” to “open”
• 

  Ross Boucher September 17th, 2008 @ 12:06 PM

  • Assigned user set to “Ross Boucher”
  • State changed from “open” to “invalid”
  • Tag changed from “api, callback, inflexible, json, remote” to “api, callback, inflexible, json, remote”

  After talking to the jQuery people, and having received no feedback on this ticket, I'm closing it. I believe this is not an issue.

• 

  Tom Robinson September 17th, 2008 @ 01:31 PM

  I feel like I've come across APIs like Jeremy mentioned (where the callback is hardcoded) but I can't think of any off the top of my head. While these APIs shouldn't be considered "JSONP", if they're common it might be worth having CPJSONPConnection work with them.

  Jeremy, can you provide us with examples?

• You flagged this item as spam.
  

  Jeremy Johnstone September 17th, 2008 @ 01:47 PM

  They might not be classified as "JSONP", but are very much "JSON". Here's one example of such an API which wouldn't be supported by the class as written (that said, it would be pretty easy to modify the class to support it).

  http://developer.yahoo.com/addre...

  Being that Yahoo! AddressBook is the world's largest online addressbook, it does seem silly to not support the interaction model used by it (and others) just because it's not "JSONP" and rather straight JSON.

  Essentially here's where I stand, if all you want to support is insecure access (for the most part, you won't find "secure" data being served via JSONP do to the abuse potential for such an API) via JSONP and nothing else, then sure, this is an invalid bug. But if you would prefer to support a wider range of JSON apis then this class should probably be extended or a new class made with shared code between them moved up a level in the parentage.

• 

  Ross Boucher September 17th, 2008 @ 01:57 PM

  This isn't a JSONP api. You can't use this API from the client side no matter what we do, because it would violate the same origin policy.

  JSONP (and this class) is only for APIs that use JSONP to get around the same origin policy. If you're just using JSON data from your own domain (the only way to use XMLHTTPRequests), then you can use the normal CPURLConnection mechanism.

  If you want to use other JSON APIs that don't support JSONP, you need to proxy that through a server on your own domain.

• You flagged this item as spam.
  

  Jeremy Johnstone September 17th, 2008 @ 04:37 PM

  I'll just write my own CPJSONConnection.j class (notice the sans P) which provides the desired functionality. Thanks for ignoring that part of my previous post and repeating the obvious. ;)

• 

  Ross Boucher September 17th, 2008 @ 05:39 PM

  Jeremy, what I'm saying is, this functionality already exists in CPURLConnection. All you need to do is implement:

  
  -(void)connection:(CPURLConnection)aConnection didReceiveData:(CPString)data
  {
    var myJSObject = CPJSObjectCreateWithJSON(data);
  
    //do whatever you want with the javascript object
  
  }