Inviting JSON to the Table

Daryl L. L. Houston — Tue, 07 Mar 2006 15:04:10 +0000

I’m doing some preliminary work on a project for which it’s been suggested that I consider using JSON rather than XML as a data transport. “JSON?” you ask. “What’s that?” It stands for JavaScript Object Notation, and for those of us who’ve spent a lot of time writing javascript, it’ll look very familiar. It’s a subset of the javascript language and can be described as the convention whereby one represents object members as name/value pairs. In short, it’s a form of serialization native to javascript and is therefore understood by all modern browsers out of the box and by many other programming languages either natively or by simple extension. A javascript function can eval a JSON text string with no additional parsing needed and can then use the decoded values directly. This can be beneficial to web applications in at least two potentially notable ways:

It eliminates the need to parse a verbose XML document into an object and then perform operations on the object.
The format can be (though isn’t necessarily) less verbose than XML.

Transfer time and processing overhead can therefore be optimized when using JSON in some circumstances. Furthermore, for some uses, JSON might actually save programming effort required on the server side to generate XML from objects or on the client side going in the other direction.

Those advantages notwithstanding, I was originally hesitant to give JSON more than a passing glance. For most web applications that feature the sort of functionality I had in mind (including, as far as I was aware at the time, the one I’m doing R&D for), existing AJAX toolkits fit the bill, and I was inclined to use an existing AJAX toolkit rather than to implement JSON for the sheer novelty of doing so. Consider an editable grid table, for example. You have a text field with an onchange event. On change, you send a small piece of data to the server and you get a small piece of data back that tells the client how to provide UI feedback. None of the three benefits of JSON I mentioned above really apply here, as the data in both directions is small, requires almost no processing, and need not be an otherwise usable object. It’s text out, text in, and minor DOM manipulation. In such a case, JSON provides no real advantage, and you might as well go with a standard AJAX toolkit.

A colleague working on the project with me pointed out some other possible use cases, however, that might render JSON worth further investigation. For example, if the data comes down as an object, it can be sorted and have calculations performed on it more readily on the client side without a round-trip to the server and back per operation. There’s something very appealing to me about this. So I’ll be doing more diligence on JSON.

As my first foray into coding with JSON, I wanted to test the example my colleague brought up. Doing so required me to grab a few libraries, and I haven’t packaged it all up nicely, but it’d be reasonably easy to assemble these things and test this out for yourself if you’re interested. Here’s what you need to grab:

Services_JSON PEAR class
sorttable.js (for client-side js table sorting goodness; this thing is superb and is a new find for me)
oyXMLRPC.js or some other xmlrpc library for js; I modified this one to make it POST-friendly

So, in a web sandbox, save the PEAR class as JSON.php and create a file named “process.php” with the following contents:

 $i);
for($j=0; $j<$colcount; $j++){
$row[$cols[$j] ] = substr(md5(microtime() . $cols[$colcount]),0,8);
}
array_push($rows, $row);
}

$response=array(
"error"         => "0",
"message"       => "success",
"payload"       => $rows
);

$json = new Services_JSON();
$output = $json->encode($response);
print($output);

?>

This script generates 100 rows of 20 columns of junk data and returns it as a JSON object. In a real-world application, this would presumably be a data set returned from a database. The XMLHttpRequest issued from your client calls this script and handles the data. Now on to that part of the code. Create a file named index.html and populate it as follows:



JSON Demo

Note the javascript includes at the top, and be sure to name the downloaded libraries appropriately or to change the file. Now create json.js and populate it as follows:

function json_request(txt){

var myOnComplete = function(responseText, responseXML){
var obj = eval('(' + responseText + ')');
var container=document.getElementById('container');
container.appendChild(make_table(obj.payload));
sortables_init();
}

var myOnLog = function(msg){
alert(msg);
}

var provider = new oyXMLRPCProvider();
provider.onComplete = myOnComplete;
provider.onError = myOnLog;

provider.submit("process.php?txt=" + escape(txt));
}

function make_table(data){
var table = document.createElement('table');
table.className='sortable';
var tbody = document.createElement('tbody');
for(var i=0; i
If you get everything linked up correctly, the result should be that when you press the button on the main page, a JSON object is pulled down asynchronously from the server and appended to the page as a table of data. Each such table is independently sortable without round trips to the server and back (and without your having to write sorting validation code to prevent SQL injection attacks, etc.). Of course, this does degrade poorly for browsers in which javascript is disabled. In any case, I’ve modeled one bit of functionality that’s pretty painless to implement using JSON, and I suspect that further work in this direction will turn up even more interesting results.
For more information on JSON, be sure to hit the JSON site.

technorati tags: json, ajax, javascript

Xajax in Drupal

Daryl L. L. Houston — Mon, 21 Nov 2005 08:29:03 +0000

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.

Two Ells » ajax

Inviting JSON to the Table

Xajax in Drupal