If you haven't heard of JSON (JavaScript Object Notation), I think the simplest way to think of it is as a serialized form of data. Much like the old CFWDDX that few people use anymore, JSON is a way to take some data, any data, and convert it into a string. Like WDDX, you can both serialize and deserialize JSON data.
One of the benefits of JSON is that it is a lot less weightier than XML. While it isn't nearly as readable, when it comes to AJAX it has the benefit of simply shifting less bits back and forth while passing the same information.
I had not really paid much attention to JSON, but with the size issues cropping up in ColdFire, I took a look and I was really surprised by how much JSON cuts down on the size of the data. Consider the following code:
<cfset data = queryNew("id,name,age,active","integer,varchar,integer,bit")>
<cfloop index="x" from="1" to="100">
<cfset queryAddRow(data)>
<cfset querySetCell(data,"id",x)>
<cfset querySetCell(data,"name","User #x#")>
<cfset querySetCell(data,"age",randRange(20,90))>
<cfset querySetCell(data,"active",false)>
</cfloop>
This creates a rather simple query of 100 rows. I'll use my toXML CFC to convert this into an XML packet and then report on the size:
<cfset xmlVersion = queryToXML(data,"people","people")>
<cfoutput>
<h2>XML Version (#len(xmlVersion)# chars)</h2>
#htmlCodeFormat(xmlVersion)#
</cfoutput>
I ended up with a string that was 7939 characters long. Now lets convert that to JSON using CFJSON from Thomas Messier.
<cfset jsonVersion = encode(data)>
<cfoutput>
<h2>JSON Version (#len(jsonVersion)# chars)</h2>
#htmlCodeFormat(jsonVersion)#
</cfoutput>
Size of the JSON packet? 1881 characters. That's pretty significant. Spry does not yet support JSON, but when/if it does, I certainly plan on switching where appropriate.
Archived Comments
Thats some really significant savings. I'm glad you posted this because I've never had time/anything applicable to really look at JSON with.
There was a post on the spry forums way back that someone implemented their own JSON into spry 1.3
http://www.adobe.com/cfusio...
Andy Powell spoke at the Nashville CFUG on Spry. If I recall, he said that Adobe was planning on implementing JSON into the final release version of Spry. Just FYI.
I love JSON. I had a similar experience where I could measure my AJAX packets in kilobytes with XML, but in bytes with JSON.
I also found JSON easier to generate, but now with tools like toXML and CFJSON, that's irrelevant. :-)
I haven't stepped out of the Prototype/JSON world yet.. My problem (if you could call it that) is that I actually LIKE JavaScript, so I don't mind some of the manual higher-level AJAX processing that you do when you just have Prototype. But your Spry preso a few weeks back really impressed on me how quickly Spry lets you implement basic AJAX functionality!!
The "final" release of Spry being the final final? You mean, in the next version, right?
JSON is a pretty nifty way to serialize data and is for sure less dense than XML, but it's also a good way to introduce security holes in your applications if you're not careful...
There's a tendency to just eval() the response in the browser since its JavaScript anyway, but that leaves your application open for some very nasty XSS attacks.
Always make sure you validate the result in the browser before eval'ing it. :)
(Note that the JSON library at json.org does this for you.)
@Lola: I believe he means "Final" as in the non-beta release. Even though it is a 1.x release, it's a beta.
@Elliott: I'm aware of the danger of XSS in AJAX/JSON, but frankly I don't understand logistically how this can happen since by default the AJAX will only accept responses from the same server. How can XSS occur?
@Joshua:
Well it depends entirely on how the JSON is requested. Ajax is often used to mean using a XMLHTTPRequest, but in practice iframes and script tags get used too which open different attack vectors.
In the case of a XMLHTTP request a "man in the middle" attack is one example. If you're using an XMLHTTP driven admin section on your site, lets say your blog, and I return a JSON packet to your client that selects all the entries and submit()'s them for deletion you'd be rather unhappy. Of course a blog is a trivial case, something far worse could happen in other places. Of course HTTPS helps quite a bit in such cases.
Now if we think about XML here, no combination of XML response data on the page can create an unexpected "delete" operation.
Its the same reason that its bad practice to evaluate() CF code even if the code you're evaluating is only coming from another server inside the internal network... You're leaving yourself open for potential attacks.
If you google around you can find other examples of JSON security issues.
Here's an interesting one about CSRF: http://getahead.org/blog/jo...
Took your advice on the JSON format but have a question...
I used CFJSON to convert a query object and it gives me recordcount, columns, and data, etc but how do I output it using spry:repeat...
var mydata = new Spry.Data.JSONDataSet(getURL(), { path: "data" });
That's what I changed the XMLDataSet to and it's outputting the data as one line with comma separated...
Any pointers?
Most likely you need to add this to your options for your DS:
pathIsObjectOfArrays: true