There's roughly two ways of addressing Ajax on your website:
- Designing your pages with Ajax in mind. This usually means you'll have a growing number of features that require JavaScript to work. The W3C recommendation specifies that you should provide JavaScript-less versions of your features. So it means you will have to develop your features twice to maintain accessibility. Sounds a painful thing to do.
- Designing your pages without Ajax in mind. This means you design only good old pure html/params & forms techniques to animate your features. This is good for accessibility, this is good for testability, this is good for search engines because all your features are accessible via plain links. The only problem is... well there's no Ajax coolness.
But we're going to fix that, and it's not going to be painful at all providing you:
- have got zero business logic in your rendering layer. Meaning each part of it is idempotent. This is hopefully the case when you use a MVC model for your application.
- use a rendering layer that's capable of manipulating its buffer, and renders the whole page in this buffer before sending it.
For this post, I'll be using
Catalyst as the MVC and
HTML::Mason as the View layer. We'll focus on implementing Ajax results paging. (Other ajax aspects will be dealt with in later posts).
Principle of ajax page slices.
The idea of page slices came to me when I was looking at
jQuery's load function. It's got a very convenient trick called 'load page fragments' that allows you to do stuff like:
$('#container').load('page_url?offset=2 #result_id');
It will look for an element having the id
'result_id' in the returned document and replace the content of #container with it. Here's a full example of html/javascript that implements this:
<div class="container">
<div class="result" id="result_id">
<p>This is page 1</p>
<p>item 1</p>
<p>item 2</p>
<a class="page" href="page_url?page=2">Go to page 2</a>
</div>
</div>
<script>
$(document).ready(function(){
$('a.page').live('click',function(e){
var a = $(e.target);
var result = a.closest('.result');
var container = result.closest('.container');
container.load(a.attr('href') + ' #' + result.attr('id'));
});
});
</script>
This does the trick on the client size but it doesn't save much time on the server side.
Plus it requires DOM parsing of the whole document to find the result_id element. Altogether, chances are that your ajax paging will be slower that a simple whole page reload. To fix that, we're going make the server output only the required slice for us.
Let the server do the work.
First let's have a look first at the intended client side code:
<div class="container" id="result_id">
<!-- This is the slice 'result_id' -->
<p>This is page 1</p>
<p>item 1</p>
<p>item 2</p>
<a class="page" href="page_url?page=2">Go to page 2</a>
<!-- End of slice -->
</div>
<script>
$(document).ready(function(){
$('a.page').live('click',function(e){
var a = $(e.target);
var container = result.closest('.container');
container.load(a.attr('href'), { page_slice: container.attr('id') });
});
});
</script>
On the server side, we need a technique to output only the required slice, discarding any previously generated HTML, and aborting the rendering so no more subsequent HMTL is rendered. In Mason, this is easily done by implementing a content wrapping component.
Here's how it looks in under Catalyst (the
$c bit):
Component
page_slice.mas:
<%args>
$slice_id
</%args>
<%init>
my $requested_slice = $c->req->param('page_slice');
if( ( $requested_slice // '' ) eq $slice_id ){
# Discard any previously generated content,
# output the content and finish rendering
$m->clear_buffer();
$m->out_method->($m->content);
$m->abort();
}else{
# This component is transparent
$m->out_method->($m->content);
}
</%init>
Here's how to use this component in your
page.mas:
% deal with param('page') to compute results and next page.
<div class="container" id="result_id">
<&| /page_slice.mas , slice_id => 'result_id' &>
<!-- This is the slice 'result_id' -->
% # Output the right results
% ...
<a class="page" href="page_url?page=<% $next_page %>">Go to page <% $next_page %></a>
<!-- End of slice -->
</&>
</div>
<script>
$(document).ready(function(){
$('a.page').live('click',function(e){
var a = $(e.target);
var container = result.closest('.container');
// Use the container ID as the slice ID.
container.load(a.attr('href'), { page_slice: container.attr('id') });
});
});
</script>
When clicking a '.page' link, a request will be sent with the param 'page_slice'. Thanks to this, the component page_slice.mas will output only the requested page slice, and this will populate the container.
Your paging will obviously works without JavaScript. There's no Ajax specific code at server side. This is:
- Good for accessibility. Try using your paging with lynx. It just works.
- Good for SEO. Our beloved search engines will crawl these links, even if they don't do Ajax.
- Good for testing. Because Ajax is not needed to use your application, you can easily unit test your features from your web test suite.
- Good for reliability. If for some reason your JavaScript is broken, the feature will still be available.
Of course this technique can be applied to any kind of browsing features: sorting, faceting etc..
Next time we'll discuss performing an action in Ajax, and managing Ajax redirections.
I hope you enjoyed this post, thanks for reading!
