Slides from barCamp Copenhagen 2008

Here are the slides and the transcript of my presentation at barCamp Copenhagen 2008. The presentation was held in Danish, so I've translated the slides and the transcript into English.

Transcript

Hi, my name is Troels, I work for a company called beaconware.

I primarily work with .net technology and web development.

I would like to tell you about ajax and about how you go from ajax to hijax to indirect ajax.

I'll round this session of with a demo about how indirect ajax works.

There are a lot of definitions of what ajax is. A simple definition would be:

"Ajax is the ability to update a part of the page instead of the whole page."

It may not sound overwhelming.

The strength lies in the ability to call the server asynchronously without reloading the page.

An example could be an explorer in a CMS with folders that you can expand to reveal documents and sub folders.

You could achieve this with ajax by attaching a handler on the click event.

The handler would call a web service asynchronously to get a data representation of the contents of the folder.

Then it would add graphics needed for documents and sub folders to the document structure below the expanded folder.

The great challenge in programming ajax is to make it work in all browsers.

It's difficult and the end user must often download huge scripts to make it work.

Browsers in cell phones has extra difficulties with ajax because they don't have full dynamic html support.

If you make your web application depend on ajax, then you have to realize that there will be end users

who are unable to use it, either because of their browsers or because of other accesibility concerns.

That's why it's so important to make sure that the ajax application degrades gracefully, which means that beneath

all the fancy web 2.0 fireworks there's a fully functional web 1.0 document to fall-back on.

This is where hijax gets into play.

Hijax is a method that reminds you of how you achieve separation of layout from document structure by using css files.

With hijax you achieve separation of ajax from the document structure.

The procedure is to start by developing a fully functional web 1.0 document by using forms and links.

Then you hijack the form's "onsubmit" event and the link's "onclick" event by using unobtrusive Javascript.

That means Javascript that automatically disables itself in a down-level browser.

So, if the browser doesn't live up to the requirements for ajax then the application reverts to web 1.0 behaviour.

When a form's onsubmit event has been hijacked and it gets intercepted then an asynchronous call is made to a web service on the server.

The server returns the requested html fragment and the client updates the DOM.

The technique used here is also called AHAH which stands for Asynchronous Html And Http. You can find it on microformats.org.

Hijax requires that you in your server code is able to separate the output into those html fragments that you want to update separately on the client.

So you need a really flexible server API that can return parts of the page by request.

It can seem as a comprehensive task to make your web application ready for this and it is, especially if you don't do it from the beginning.

You will have to create web services that you can call and a way of telling them which part of which page that you want html returned for.

Not to mention thinking up a way of handling actions and events on the server.

That is why some people gone a step further and invented indirect ajax.

Indirect ajax automates the process of hijaxing a form.

It hijacks all events and communicates with the server through a proxy.

The proxy receives enough information to execute the http request that would have been executed if the event hadn't been intercepted.

The only difference is that the call is executed locally on the server and a lot faster.

The html document that is returned by this call is stored in memory on the server to be compared with the html document returned by the next call.

So, on every request the current document is compared to the previous document.

The comparison results in a difference. This difference consists of a number of html fragments together with information about where they belong in the document structure.

This information is sent back to the client that now updates the document structure.

On the screen it looks like the browser executes a normal post back. It's just quicker, because:

- The traffic to and from the server has been minimized.

- and because the call is executed locally on the server

- and because it doesn't require the whole page to be reloaded.

Now I want to show you a couple of demoes of an indirect ajax framework.

It's an open source project that I have developed for .net and it's called OutPost.

You can try out or download the demo from http://hijax.net/OutPost.

The first demo is inspired by Google Suggest which is a really classic ajax tool.

As you type in words in the search field the suggestions for search terms are shown below based on searches of other users.

I twisted it and made a Farber Suggest application based on the hilarious turns of phrases of David Farber.

Here you type in an English word and then a number of matching farberisms are shown below.

Let's try...

The other demo is a simple explorer that shows folders and documents in a CMS.

You can click on a folder to expand it.

You can also collapse the folder again by clicking on it.

In the background I have a program called Fiddler running. It logs the traffic between client and server.

As you can see the server sends about 8kb back on every request.

Now I enable OutPost.

And run the demo again.

Looking at the source code you can see that some details in the html code has changed to make OutPost able to hijack the events that normally gets the browser to reload the page.

Then we expand the folder... And expand the sub folder...

And then we switch to Fiddler again.

As you can see the amount of traffic is now about 10 times smaller.

This is partly a result of zipping the traffic. So, we use Fiddler to unzip it.

And if we dive deeper in to see the data itself we can see that it's not a full document that's returned to the client.

The client receives commands that the OutPost client framework understands and uses to update the document structure with.

As an example one command means "replace this image with this" and another means "delete this table".