We've expanded our Perl news coverage and improved our search! Search for all things Perl across O'Reilly!

Using Ajax from Perl
by Dominic Mitchell | Pages: 1, 2, 3, 4

Inside CGI::Ajax

Now you know how to use CGI::Ajax to update your web pages dynamically. What actually happens inside to make it all work? You've already seen how the JavaScript version of check_username() gathers the values from the input fields and passes them back to your original CGI script. You can see the calls that happen when you insert an extra line into the script, just after you create the CGI::Ajax object.

$ajax->JSDEBUG(1);

With that in place, CGI::Ajax will log each call that it makes to the server at the bottom of your web page. On my server, it looks something like this:

http://localhost/~dom/cgi-ajax/ajax.cgi?fname=check_username&args=dom&user=dom

If you click on the link, you'll see that it returns the string Username 'dom' taken! and nothing else. It completely ignores the bulk of the program and just sends the result of check_username(). When the main part of the program calls $ajax->build_html(), CGI::Ajax checks for the presence of a parameter called fname. If it finds one, then it checks to see if that function has been registered. If so, it calls it, passing in any args parameters. It then returns the results of that single function back to the browser, completely sidestepping the main program.

CGI::Ajax in the Real World

Ajax is a tool, just like the many others you already have available when programming for the Web. There are places when it's more or less appropriate to use it, the same as table elements in HTML. The reason I chose username validation as an example is because I think it's a good example of where Ajax can be used to really add something to an existing web application. Using Ajax to enhance forms, particularly long complicated ones, can work wonders for usability. There are other places, as well. As I pointed out at the start with Flickr, inline editing can be a great boon.

Like all tools, knowing when not to use it is as important as when to use it. Packages like CGI::Ajax make it astonishingly easy to use Ajax, so you need to exercise restraint. It's all too simple to add a dash of Ajax where perhaps it would be more appropriate to reload the whole page. If you find that you're updating most of the page with an Ajax call, then it's more than likely not worth bothering with Ajax at all. Really, the best guideline is to do some usability testing. Think about how your users interact with your application. What's the best way that you can help them achieve what they are trying to do?

There are several good resources available for deciding when to and not to use Ajax. The most complete appears to be Ajax Patterns, which should arrive as an O'Reilly book at some time. A weblog post from Alex Bosworth gives his opinions on "Ten Places You Must Use Ajax" (even though it's only really six). Alex also has a good piece on "Ajax Mistakes," which is also worth paying attention to.

There are also technical reasons to consider when implementing Ajax in your application. You have to realize that any user at all can access the server-side functions that you are exposing, even though you might think of them as internal-only. Your application suddenly has an API. For security or performance reasons, you might want to reconsider what you are exposing (although this advice applies equally well to regular web pages in your application). Also note that the API that you get from CGI::Ajax binds tightly to the internals of your application. If you change the name of an exported function, you have just changed the API. If the API is part of a large, ongoing project, you might wish to consider spending some time looking at more REST-like interfaces instead. These tend to be easier to work with for programmers in other languages.

Now that your site actually has an API, you might want to consider documenting how it works so that your users can build on it. This is something that Flickr has done to great effect. There are now tools that exist that the Flickr folk had never thought about, simply because they let their users get access to an API.

Don't let all this deter you; you've seen how easy it is to add some sparkle to your application. Have a think about how you can make your users' lives easier.