I’m much more typo-prone than I used to be. Strictly speaking, I’m not only more typo-prone, but more usage-error-prone as well. For example, it used to be that if my fingers typed “it’s” for “its,” I’d auto-correct without even consciously thinking about it. I knew better, but my fingers made a mistake, and my brain reacted quickly enough to the muscle mistake that it told my fingers to correct even before I consciously registered that I had typoed. Lately I find that my brain doesn’t correct as quickly or necessarily even automatically. I’ll review posts after publishing and find typos and spelling errors that I didn’t catch. (I’ve always been a near perfect speller and have had the same auto-correct mechanism for spelling goofs.) Sometimes I never catch them and they have to be pointed out to me. To my credit, this is partially because I’m usually posting in a hurry, and it’s not like I’m publishing in the New York Times here, after all, so who cares? But I do care, not out of any concern for you, my precious three readers, but out of a sense of pride. I’ve always been pleased with my ability to auto-correct, my near-impeccable spelling and grammar. To see it deteriorating (largely through lack of directed exercise) is painful. I’ve been staring at blocks of code for too long, I think. Luckily, in my latest job shift, I find myself doing more writing. I do reasonably well-thought-out blog posts at my other blog several times a week. Here’s hoping that exercising my proofreading muscles a bit more strenuously as I’ve been trying to do will pay off. Do me a favor and keep an eye out for my long slide into incomprehensibility; if I slide very far at all, do let me know, preferably employing good usage and grammar in order to set a good example.

I’ve taken a little break from tech postings here because most of my tech postings of late had been about Flock, and I wanted to group those elsewhere. Here’s another tech posting that’s relevant to Flock because I wrote this code for a project for Flock, but it doesn’t exactly belong at that blog because it’s not specifically about Flock. So feel free to skip over this one, dear family members.

Xajax is a php library that makes ajax development a cinch. I’ve looked at a few ajax libraries, and there are better implementations than what xajax provides on the javascript side, but the ease with which one correlates php function calls to javascript function calls in xajax is well worth the reduced functionality in many cases. For example, xajax doesn’t (as far as I’ve investigated, at least) provide elegant drag and drop functionality. But for simple updating of content upon request completion, it handles the basics without forcing you to write your own javascript callback functions (which can be a pain and which can make your source code look really nasty). Here’s a quick primer on how it works:

• Write php functions to do server-side data manipulation and to use xajax calls to manipulate the page upon request return.
• Register these functions in your php script. This gets the correlating javascript functions added to the javascript include.
• Include the javascript in your source, tell xajax to process requests, etc. (all this is outlined in detail at the xajax site).
• Add the javascript function calls to your source. If your php function was named “delete_member,” your javascript call is named “xajax_delete_member.”

That’s it. Arguments passed to the js function are passed straight through to the php function, and you have to do no special mumbo jumbo to make the thing work. The out-of-the-box functionality is pretty simple when compared to the libraries available at, for example, script.aculo.us, but xajax is reportedly extensible, so you’re certainly not limited to what you get out of the box.

Now, on to why this is ideal for Drupal development. The more I use Drupal, the more appealing I find its API. It’s pretty simple to extend the software. For example, I recently wanted to add a little snippet of code next to the title of any sort of node. Lucky for me, the Drupal developers thought to include a nodeapi hook, which lets you do just what I wanted to do. For all its niceness in some areas, though, it’s painful to do some things in Drupal. Adding global ajax support seemed a likely candidate for such pain because Drupal’s got menu hooks, a permissions system, etc., that I thought might make for tedious hacking.

I started by simply including the xajax code in one module I was working on (as proposed here), but when I wanted to include the same sort of functionality in another module, I started getting collisions. The library code was called more than once, so I found myself getting php errors. This prompted me to try to find a way to make xajax work globally across a Drupal install. And it turned out to be dead simple. I simply included the xajax library as in the example linked to above. If the node is enabled, this adds the javascript include to the template globally. Then I added some code that checks all installed Drupal modules for a function named MODULE_xajax_init (where “MODULE” is the module name). This init function for relevant modules performs the function registration calls. The routine for adding ajax support to any module in Drupal, then, now goes as follows:

• Install and enable xajax.module.
• For the module you’re writing, define MODULE_xajax_init and include function registration calls.
• Within your module, define the php functions you’ve registered.
• Add javascript calls to your UI.

That’s it. Voila. Magic, easy ajax support in Drupal.

Xajax is especially suited to Drupal because it handles everything using simple php code. There’s no writing of nasty javascript callbacks and embedding those into your templates or, worse, into your module itself. The appeal of using this xajax module is that it works globally across your Drupal install with no “function already defined” type errors and, well, it’s done and it’s free. You can download the module here.