Opened 16 years ago
Closed 15 years ago
#1117 closed defect (fixed)
BrowserIO.js handles text/json incorrectly
Reported by: | guest | Owned by: | alex |
---|---|---|---|
Priority: | high | Milestone: | 1.0 |
Component: | IO | Version: | 0.3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
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.
Change History (4)
comment:1 Changed 16 years ago by
Milestone: | → 0.9 |
---|
comment:2 Changed 16 years ago by
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.
comment:3 Changed 16 years ago by
Milestone: | 0.9 → 0.6 |
---|
comment:4 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
Discussed this with Alex a bit.