I'm using JSON.parse function to load info about a cellset. I'm testing how much data is possible to fetch in one call.
The eval function starts throwing "out of memory" between 1.3-1.4 million characters (65,000-70,000 cells) in the JSON string. Does anybody know of a workaround for this - perhaps a pure JSON parser, rather than eval?
Thanks,
Nathan
I would recommend this one: http://json.org/js.html it's efficient.
You are definitely pushing way too much information to your client.
Possible workarounds:
Page your data and only load what is visible
Avoid JSON, use HTML and dump the HTML directly to the page with .innerHTML
Maybe use a native JSON parser like in Firefox and IE8 (possibly in other browsers, can't remember)
Try JSONP (including a script tag that calls a function with your data as an argument)
Related
Here's the two scenarios.
We are using a manually built xml soap request with xmlhttprequest, sending it to a wcf soap service, getting back the response and using xPath to parse the data and fill out a drop down list.
We are sending a json request to a rest wcf service and getting a json response back and assigning the values to a drop down list
Which scenario is faster? My sense tells me #2 but I could be wrong.
Json will be faster, since Json is essentially Javascript. But that shouldn't be the main motivation. Parsing the data, will assumingly be only a small part of your application anyway.
On the other hand, browsers are also well trained to parse XML.
The main difference is that XML, and therefor SOAP, is larger to send to the client, so the transfer may be a bigger slowdown than the parsing.
Anyway, if you want to know, you should just test and profile instead of guessing or asking.
Option two would generally be faster than option one, as JSON is a much simpler format than XML.
However, if you really need the parsing to be fast, you shouldn't use either, you should use a custom format that is really fast to parse using simple string operations. For example a comma separated string that could be parsed with a split(',').
After profiling in my scenario, I found out that JSON is actually much faster as far as processing time within the browser
New to JSON, just trying to get my feet wet.
I know how to do this with XML via javascript, but am trying to learn how to handle JSON objects so I can switch over.
Basically I want to search through all "permalink" tags in the following JSON object and, when I find the right one, save its corresponding "title" and "id" tags to javascript variables:
http://api.soundcloud.com/users/goldenstatewarriors/tracks.json?client_id=02db8e29aa2fb5bf590f478b73137c67
Can this be done with only javascript (no PHP)? The main issue I'm facing is simply grabbing the text from the page and converting it to a json object.
You need to use a JSON parser in order to transform the JSON string into an object you can handle natively in JavaScript. Recent browsers have this functionality built in as JSON.parse(), but obviously this will not work in older browsers (we're talking very old browsers here).
A solution to that problem is to use the JSON parsing library available here. If native browser support is detected, it simply uses that, otherwise it has a JavaScript implementation to achieve the same result. The file you'll need is json2.js - simply include that as you would any other library and away you go!
An example of the code would be:
var dataObject = JSON.parse(jsonData);
As a side note, XMLHttpRequest is somewhat of a misnomer these days. It is simply a mechanism for making HTTP requests and retrieving the data returned, it doesn't have to be XML. It can be plain text, (non X)HTML, JSON, anything. In fact, I don't think I've seen anything in the wild return actual XML data for an XMLHttpRequest in a very long time.
Does anyone readily know if using eval() and responseText (using JSON) is faster or slower than just using responseXML?
I would imagine avoiding the eval() and using responseXML instead would be faster, despite the fact that you gotta write really long code to actually get the values of the XML.
Thanks.
Actually JSON data are most of the time smaller than XML.
It is better to not use eval() because it is a well known security leak. But I've heard of regular expression which can check the JSON compliance.
I do not like XML so I avoid it, but I suppose that the responseXML will build a DOM model which is much more heavier than the native javascript objects created by responseText
I you want to minimize the bandwidth JSON is probably a better choice than XML.
Use JSON and use a parser instead of eval. Here's one - https://github.com/douglascrockford/JSON-js
Internally, Firefox will JSON encode an object passed via postMessage to and from the Web Worker. However, this only works in Trunk builds of Firefox (3.6+) and not in Firefox 3.5, so the question is really how to add backwards support of this operation to the current platform. The window.atob() and window.btoa() methods had been suggested before, but alas these are not available internally to the threads because they don't have access to the DOM.
Mozilla publicly states this on their developer wiki, but it has been noticed by many in the community that this happens. Check ejohn's blog test: http://ejohn.org/files/bugs/postMessage/
I've verified that this is the case as well, in 3.5, it passes only strings, and in 3.6 is will pass the object.
I haven't noticed the automatic JSON-encoding not working in Firefox 3.5, but I've mainly been working with Gears, which doesn't support it anyway.
Try including a JSON utility in both the worker script and the parent script, then manually encode and decode it yourself. This works fairly well for me with Gears.
This approach shouldn't break when Firefox begins automatically doing the JSON encoding for you, since the encoded JSON string will remain a string.
In JavaScript there are two functions respectively for decoding and encoding base64 strings:
atob()
btoa()
I found the solution to my own problem!
It seems that if the thread variable, even if declared globally, loses its .onmessage property if that said property was declared inside another function. If the property is instantiated on the global scope, then JSON messages are parsed correctly.
I'm still not sure I understand what's going on here, but at least I've figured out a way to pass objects around without having to rely on any additional stingify/json libraries.
If anyone could explain this to me so I have a better understanding, it would be appreciated :)
I setup a test case here: http://x.miernicki.com/ which logs the inter-thread messages to the firebug console if anyone cares. This helped me to get objects passed around in Fox3.5 and ultimately allowed me to see what the problem was.
Since you are clearly looking for a FF-only solution, have you tried yourObject.toSource()?
Quick Question. Eval in JavaScript is unsafe is it not? I have a JSON object as a string and I need to turn it into an actual object so I can obtain the data:
function PopulateSeriesFields(result)
{
data = eval('(' + result + ')');
var myFakeExample = data.exampleType
}
If it helps I am using the $.ajax method from jQuery.
Thanks
Well, safe or not, when you are using jQuery, you're better to use the $.getJSON() method, not $.ajax():
$.getJSON(url, function(data){
alert(data.exampleType);
});
eval() is usually considered safe for JSON parsing when you are only communicating with your own server and especially when you use a good JSON library on server side that guarantees that generated JSON will not contain anything nasty.
Even Douglas Crockford, the author of JSON, said that you shouldn't use eval() anywhere in your code, except for parsing JSON. See the corresponding section in his book JavaScript: The Good Parts
You should use JSON and write JSON.parse.
"Manual" parsing is too slow, so JSON.parse implementation from the library checks stuff and then ends up using eval, so it is still unsafe. But, if you are using a newer browser (IE8 or Firefox), the library code is not actually executed. Instead, native browser support kicks in, and then you are safe.
Read more here and here.
If you can't trust the source, then you're correct...eval is unsafe. It could be used to inject code into your pages.
Check out this link for a safer alternative:
JSON in Javascript
The page explains why eval is unsafe and provides a link to a JSON parser at the bottom of the page.
Unsafe? That depends on if you can trust the data.
If you can trust that the string will be JSON (and won't include, for example, functions) then it is safe.
That said - if you are using jQuery, why are you doing this manually? Use the dataType option to specify that it is JSON and let the library take care of it for you.
If you are using jQuery, as of version 1.4.1 you can use jQuery.parseJSON()
See this answer: Safe json parsing with jquery?
Using JavaScript’s eval is unsafe. Because JSON is just a subset of JavaScript but JavaScript’s eval allows any valid JavaScript.
Use a real JSON parser like the JSON parser from json.org instead.
The alternative to evaluating the code is to parse it manually. It's not as hard as it sounds but it's quite a lot heavier at runtime. You can read about it here.
The important part to note is evaluating JSON is not inherently insecure. As long as you trust the source not to balls things up. That includes making sure that things passed into the JSON encoder are properly escaped (to stop people 2 steps up the stream executing code on your users' machines).
you can try it like this
var object = new Function("return " + jsonString)()
Another great alternative is YUI:
http://yuilibrary.com/yui/docs/json/
So your code would be something like:
Y.JSON.parse('{"id": 15, "name": "something"}');