At least one good thing about getting low site hits is that every small spike in traffic is noticeable. One such spike I got recently was from the Off Topic forum at Joel On Software. Mark Warner agrees that using JavaScript as the return value of an Ajax call is a great way to exchange data between the server and client.
At Iventa, I'm currently working with a team of very talented individuals in developing a next-generation Web 2.0 application that does some really cool stuff. Needless to say, Ajax technologies are an important part of our interface design. Even if we don’t realize it, we have turned out to use exactly the same architecture that Jessie James Garret had talked about some time ago in his now-famous article. With one significant difference, though. We are still not using XML for transferring data. We don't need the X in Ajax!
What we are using, though, is JSON. JavaScript Object Notation might not be new to most people here, and it isn't rocket science either. Unfortunately, there's not enough information on the Internet that talks about using JSON well. So, well, here goes: A short tutorial on using JSON for Ajax.
We are using ASP.Net 2.0 as the core server-side technology. Personally, I hate anything to do with Microsoft, but I guess business decisions prevail over personal preferences. However, this blog is mine, and I will talk about whatever the hell I like to talk about, and I hate Microsoft, so we are not going to talk about ASP.Net here. We shall just talk about the JavaScript side of things here.
That said, the server is just as important in an Ajax call as the client. Usually, one would use a framework that would let one make "client callbacks" on the server, but this is not necessarily the only way to transmit Ajax data. One could use a more barebones language like PHP directly without any frameworks to do just that – in fact if your site uses very few Ajax calls it is probably better to avoid an Ajax framework anyway.
Back to JSON. So, when we make an Ajax call using JavaScript, the server side script fetches the data we have requested (which could be from a database or from XML files, or any other kind of storage medium). The next step would be to convert it to a format that we can use on the client. This is where JSON kicks in.
Here’s how a typical JSON string would look. I’ve added line-breaks for clarity.
{
"UserInfo": {
"id": "100",
"firstName": "Rakesh",
"lastName": "Pai",
"emailAddress": "[email protected]"
},
"MembershipInfo": {
"JoinDate": "2/31/2006",
"MemberType": "3"
}
}Now, let’s say that I have a JavaScript function defined on the client, already available in a JavaScript include that uses this function as a parameter. Most frameworks will let you define which function will be called. If not, an approach similar to what I had talked about before can be used.
So, the function will look as follows:
function showUserDetails(serializedObject) {
objResponse = eval("(" + serializedObject + ")");
// objResponse can now be used as an object with its properties set.
alert("User’s first name is " + objResponse.UserInfo.firstName);
// Process the object as required
...
}See how easy it is to use the data coming from the server? JSON makes it amazingly easy to get the data down from the server, create a neat object out of the data that has come in, and consume it the way you want to. The object, of course, can be rather complex, allowing for exchange of very complex data between the server and the browser.
This might not be the most efficient way of doing things. The comments are open for opinions.
