Thursday, May 8, 2008

Web 2.0: Client-side Views

In a previous article, We saw how DOM manipulation can become so handy using JavaScript Templates. Massive changes could be applied to the html document hierarchy using one-line JavaScript functions. In this article we will introduce a generic web development technique that we can name Client-side Views.We will build on our knowledge of JST in order to compose a closed set of tools to follow client-side views with minimal effort. At the end we will get to know the benefits obtained by following such a technique.

What is Client-side Views?

Client-side views can be defined as the concept of abstracting the server-side of a web application to respond to different actions with a standard non-graphical data format, leaving the task of forming a graphical representation of this data to its client-side. This means that the server will not respond with formatted html as usual. However, it will respond with some data format (like xml). Notice that, obviously, this technique helps future transformation of a web application into an abstract web service.

A Closed Set of Tools

Now let's introduce a closed set of tools that will help us follow client-side views with minimal effort. As it can be guessed, there is no restriction on the server-side development tools. However, on the client-side we'll stick to JavaScript, being the most famous standard client-side scripting language. In addition we'll select Prototype Ajax, JSON and JavaScript Templates.
Prototype Ajax
Protoype JS library contains a very powerful abstraction of almost all the functionality of XMLHttpRequest (xhr). Hiding most of the details, Prototype Ajax introduces a very nice interface to the native xhr Ajax. In this context, we are interested in only one api, which is "Ajax.Request". We will send an ajax request to the server, expecting it to respond with a known data format (discussed in next section). For more information about Ajax.Request api, visit its documentation page.

JSON

As mentioned before, we will send an ajax request to the server, expecting a response with an agreed on format. The most handy data format that supports our technique is JSON. JSON stands for "JavaScript object notation". It is the representation of an object in JavaScript. As we are using JavaScript as a language, we can't be happier if the server responds with the notation that JavaScript best understands. Almost all programming/scripting languages have their own libraries for JSON manipulation. For example, in Ruby on Rails, we can just call "object.to_json" to obtain the JSON representation of the ruby object. for more details about JSON and its libraries in different languages, visit json.org.

Combining with JST

Combining with JavaScript Templates (introduced in the previous articles), our adopted scenario will be a close variant of the following:

- Send an Ajax request to the server application, providing a callback that's called on success of the request.
- The server responds with JSON format of all data needed to transfer the state of the front-end representation of the application.
- On request success, the callback we provided is called. A typical client-side renderer callback will look as follows:

function callback(transport){
//evaluate the JSON string returned from the server
//(one line)
var jsData = eval( '(' + transport.responseText + ')' );

//evaluate the resulting html provided the data
//obtained from the server
var newHTML = TrimPath.processDOMTemplate('jst_id',
{ jstData: jsData } );

//insert the newly formatted html in its placeholder
$('placeholder_id').innerHTML = newHTML;
}

Hurray.. We have just transferred the view rendering logic that we used to follow on the server to the client, using a three-line JS function.

Benefits

Let's compare our technique to the traditional ajax technique of sending an ajax request, forming an html snippet at the server, and returning it to the client to insert it in its placeholder. Our benefits are:

- Ability of developing multiple clients with different graphical representation to the same web application (the concept of web services).
- Massive reduction to the server response time; the time that used to be consumed in evaluating server-side templates is now reduced and divided among other requests.
- Massive reduction to the bandwidth used; the size of JSON text of some data is dramatically less than its formatted html representation.

However, there is a disadvantage we can't totally avoid; our typical three-line rendering function incorporates extensive string processing (parsing the template and evaluating the output html using the supplied date). It's a known fact that JavaScript is relatively slow on most web browsers when it comes to string operations. So, at least, one has to watch out for the performance measure, try to optimize his code as far as possible, just not to make things worse.


No comments: