Web 2.0: Client-side Views

30Apr

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 I 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 a Client-side View?

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 the 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 upon 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 couldn’t be happier with the server responding 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 on 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 provide 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, and just not
to make things worse.

eSpace

Blogs