XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.

advertisement

The XSLDataGrid: XSLT Rocks Ajax

August 23, 2006

Most web applications have a requirement somewhere in their interface for a tabular view of data -- often, a view of the rows in a database table. In some cases, the use of a static HTML <TABLE> is appropriate, but users have become increasingly accustomed to richer, more malleable interfaces that let them change column widths, order, etc. Among the application widgets in the web developer's toolbox, the dynamic datagrid is an often cumbersome one to set up. This article will outline a datagrid component powered by XSLT and JavaScript that aims to achieve easy setup, high performance, and minimum dependence.

The Problem

There are roughly three types of approaches to using a JavaScript widget in a web application. Approach #1 involves creating a server-side object with properties (in PHP or Ruby, for instance), and then eventually calling a render method on the object that creates a XHTML string to be sent to the browser. For instance, in PHP it might look something like this:

$dg = new DataGrid();
$dg->columns = array( "field1", "field2", "field3" );
$dg->data = $data;
etc...
$dg->render();

Approach #2 is much like approach #1, except that an object is instantiated in the browser (with JavaScript), and the render method is essentially a series of Document Object Model (DOM) object creations and attachments to the browser's render tree. For example, using the ActiveWidgets Grid, the code might look like this:

var myCells = [
["MSFT","Microsoft Corporation", "314,571.156"],
["ORCL", "Oracle Corporation", "62,615.266"]
];

var myHeaders = ["Ticker", "Company Name", "Market Cap."];

// create grid object
var obj = new AW.UI.Grid;

// assign cells and headers text
obj.setCellText(myCells);
obj.setHeaderText(myHeaders);

// set number of columns/rows
obj.setColumnCount(3);
obj.setRowCount(2);

// write grid to the page
document.write(obj);

Approach #3 is a combination of approaches #1 and #2, whereby some relatively simple, declarative XHTML is used as a starting point, and some method is used to populate the render tree with extra bells and whistles. An analogy here is building a house where the declarative XHTML is the frame and the DOM additions are the siding, air conditioning, and champagne-filled hot tub!


var myGrid = new XSLDataGrid( 'renderDiv', { width: 480, height: 200, transformer:'client', debugging: true } );

Approach #1 to widget creation is the least portable, as it relies on whatever server-side language a developer is using at the time. Approach #2 will most likely degrade poorly if an end-user has disabled JavaScript in his browser; this approach also tends to perform less reliably with larger datasets. Thus, compromise -- the mother of endless tinkering -- will be our guide to Approach #3.

In Defense of the Table Tag

The advent of added and better Cascading Style Sheet (CSS) support in browsers has caused developers to reconsider their use of the <TABLE> tag. For the most part this is a great thing, as tables can be constraining and inefficient for design and layout. However, the <TABLE> tag and its children offer a declarative, semantic language for describing the presentation of tabular data that succeeds where an obscure combination of nested DIVs and float:lefts becomes cumbersome. And if a user agent has CSS disabled, the pure DIV approach to table presentation will be a mess.

Pages: 1, 2, 3

Next Pagearrow







close