BrowserIO.js handles text/json incorrectly

[guest]

in src/io/BrowserIO.js, vicinity line 258:

  }else if(kwArgs.mimetype == "text/json"){
    try{
--->  ret = dj_eval("("+http.responseText+")");
    }catch(e){
      dojo.debug(e);

Should be calling "dojo.json.evalJson()" instead of "dj_eval()", so it will pick up any JSON parsing enhancements.

[dylan]

Discussed this with Alex a bit.

• Requiring the dojo.json package for this is a lot heavyweight.

• Perhaps a return value that forks based on whether dojo.json is defined could be useful.

• That said, safe JSON instead of eval is pretty slow.

• Until XHR can be done cross-domain, what is the benefit or advantage?

[RickMorrison@…]

0.9?? Ouch!

• Requiring the dojo.json package for this is a lot heavyweight.

OK,agreed about the heavyweight. Same thing c/b accomplished in lightweight fashion by having dooj.json monkeypatch this function when loaded.

• That said, safe JSON instead of eval is pretty slow.

Crockford's latest JSON RFC has a method of looking at JSON to see if can be (somewhat) safely eval()'d. I'm working on an upcoming patch that will use that, then eval() plus a post-eval() crawl of the object to implement JSON-RPC type class hinting. That will allow things like JS Date() objects and other objects that require a JS constructor function to run to be sent via JSON.

• Until XHR can be done cross-domain, what is the benefit or advantage?

Notably the class hinting stuff above.

[James Burke]

Marking this as "fixed" for now, in 0.9. The XHR JSON eval calls go through dojo.fromJson() method. If later we want to enhance that method with fancier JSON work, we can do so without affecting the XHR APIs.