With the introduction of Ajax, the classic web-applications are moving towards sending data instead of content to the web browser (in most of the cases). The emphasis on data interchange formats is more than before. This article points out available data interchange formats.
If you consider a normal web-application (non-Ajax), server sends some content (normally, HTML content) and like a faithful servant, web browser displays it and it may have Javascript working but to a limited level. But when we talk about richness of the application, we need something more than this. Most part of how we display the content should be left to the application running in browser, so that it can change the content or even look and feel dynamically, i.e. Ajax app, especially Javascript.
As we all know, the XMLHttpRequest is the core component of Ajax and it communicates with the server to get data to display in the browser without any reload of the page. Different applications use different data formats based on their application needs.
Following types of data interchange I can think of in the industry now.
- XML (eXtensible Markup Language)
- JSON (Javascript Object Notation)
- String with delimiters
- Script-centric approach
- Classic way of sending content.
Well, first three formats together can be considered data-centric approaches. But for clarity I am separating them. Let’s discuss each of the formats individually.
XML:
XML is a web standard for data interchange formats. It’s been around for quite sometime now. The support for XML in Javascript is very good as most of the browser implemented XML DOM specifications. The main usage of XML is that structured and hierarchical data can be represented very well and it’s readable by human beings. This comes with a cost of including meta-data, which describes what that data represents. Of course, I have seen many XML documents, which you can’t make out anything from but let’s keep that aside for now. One good thing about this is its pure data representation, which lacks in HTML. (HTML represents data intermingled with styles and formatting.)
Once you get the XML content as a response to the client-side you can use XSLT to transform the data into HTML content or you can use XML DOM API to parse and access XML and form HTML content, may be using innerHTML or standard DOM API.
Let’s take an example and see how we can represent the same data/content in all the formats. The example I am going to take is folder contents’ information. The XML is self-explanatory, so I am not spending much time explaining what it represents.
<?xml version="1.0"?>
<items>
<item>
<name>Test Document</name>
<type>document</type>
<creator>Test creator</creator>
</item>
<item>
<name>Test Folder</name>
<type>folder</type>
<creator>Test Creator 2</creator>
</item>
<item>
<name>Test Shortcut</name>
<type>shortcut</type>
<creator>Test Creator 3</creator>
</item>
</items>
JSON:
JSON is a light-weight data interchange format. It’s a text (string) representation of Javascript objects. An object in Javascript is represented in key, value pairs. A key is a string enclosed in double-quotes whereas the value can be number, string, boolean (true or false), object, array or null. Following paragraph explains JSON format in brief.
The advantage of JSON is that it’s more compact than XML format and parsing JSON is a lot simpler than XML. You just need to pass JSON string to eval of Javascript or you can also download JSON parsers for different programming languages from http://www.json.org/. As we have parsers for most of the famous programming languages, it makes JSON a good data interchange format. I know that a lot of people think that eval is very evil but doing eval once to evaluate the JSON string will not cause any big performance impact. But if the data grows larger then definitely JSON will not be a good option.
Example: Let’s take the same example I represented in XML and write that in JSON format.
{items:[
{"name": "Test Document", "type": "document", "creator": "Test creator"},
{"name": "Test Folder", "type": "folder", "creator": "Test Creator 2"},
{"name": "Test Shortcut", "type": "shortcut", "creator": "Test Creator 3"}
]}
String with delimiters:
Though it’s not a standard to use a plain string with delimiters as the response format, it has some advantages. We can use regular expressions or split the string into pieces using the delimiter and use the data as an array. Not much of processing is required for parsing the string.
The problem with this approach is that we need to rely on the position of the elements. And if there is any change in the positions of the elements (data) then it requires a change in the client side code. And representing deep hierarchical data is very difficult and error-prone in this approach.
Example:
The data represented in two examples above could be represented in this approach as:
Test Document#document#Test creator$$Test Folder#folder#Test Creator 2$$Test Shortcut#shortcut#Test Creator 3
As you see this format is very compact because it doesn’t contain any meta-data but as the nested ness of data increases, like corporate taxonomy, representing that data is this fashion would definitely be a problem.
Script-centric approach:
In this approach a piece of script will sent from the server like assigning values to variables, function calls, which will be dynamically evaluated at the client side to perform the necessary actions.
The disadvantage of this approach is that it assumes some Javascript environment (like some functions defined in the page) at the client side. This means more coupling with the response with the page that’s requesting the resource.
Example: As we can’t represent data as-is and there will be piece of Javascript code as a response in this approach, there could be multiple ways you can represent this.
Response:
var matchingItems = {items:[
{"name": "Test Document", "type": "document", "creator": "Test creator"},
{"name": "Test Folder", "type": "folder", "creator": "Test Creator 2"},
{"name": "Test Shortcut", "type": "shortcut", "creator": "Test Creator 3"}
]} //new lines are just for clarity.
someMethod( matchingitems,… )
Content-Centric Approaches:
In the content-centric approach, the response from the server contains HTML content. So, the client side application (Javascript) has to take the content as is and place the content in any container using innerHTML or related methods. The advantage of this approach is that there is no explicit parsing of the data required. I used “explicit”, because internally when you use HTML content, the data has to parsed and shown in the web page. But the disadvantage is that it’s data with formatting tags. If you want to reuse the data of a response in this approach then we have to rely on DOM methods to retrieve the data, which is cumbersome.
Example:
As the response would be in HTML format, we can represent this in many ways depending on the need. Here is a way:
Response:
<div><span>Test Document</span><span>document</span><span>Test Creator</span></div>
<div><span>Test Folder</span><span>folder</span><span>Test Creator2</span></div>
<div><span>Test Shortcut</span><span>shortcut</span><span>Test Creator3</span></div>
We can take this content as-is and insert as HTML content in any of the allowed elements using innerHTML (or related) method. There’s not much processing required at the client side.
Sites/Apps using these formats:
XML:
Script-centric approach:
JSON format:
Conclusion: Depending on application needs, appropriate data interchange format has to be chosen. This article just describes the options available and the decision is yours.
I’ll update this article whenever I get some more time.
No comments:
Post a Comment