Evolution of your engineering skill is also a vital trait in this world, which means that as a developer increases his knowledge of good practices and proper methods, sometimes he must shirk his previous assertions about the world as he previously knew it. And today I’m shirking a staple of the front end as all web users know it: The Grid (DataTable) Component.

Of course, I’ve written a few articles in the past about the YUI DataTable, during my long love affair with Yahoo’s User Interface library. Another popular one is jQuery’s TableSorter. Then there’s the Dojo Grid, a component inherited from TurboAjax. ExtJS has a variety of nice examples as well for their Ext 2.0 Grid.

And after using these Grids and DataTables, I certainly respect the programming that went into developing these components. But let’s take a step back for a second. Why do the users need the bells and whistles in these components? Are they worth the extra load time and complexity they add to the interface?

All we’re doing here is putting a nice coat of paint on a <table> tag. Sure, it might have some nice ancillary features like Ajax Data Loading, but those don’t really matter – they are things that can be easily performed with some good Ajax and DOM insert utility functions. In fact, most of the core features included in these components could be described as feature creep, and not beneficial to the end user at all. Feature creep contributes to code bloat, which means the user is downloading bytes to their web browser that they don’t need, which can hamper performance. Libraries usually have online examples of their components, and the include sizes are seen below. (Gzip compression not considered)

The JavaScript include sizes listed above are directly proportional to the feature set that the components provide, and should give you an idea of the overhead involved with using them. Do we need 545.5 KB of features coming down the pipe to give our users an extra bell, or an extra whistle? Let’s analyze the features to rationalize their usage, and remove items from the feature set.

• Sorting
• Modifying column order and display
• Resizing columns
• Editing of row data directly on the grid itself
• Scrolling
• Pagination

Sorting

Data should be used in the context of its usefulness. You have a list of messages in your e-mail inbox. What’s the most useful context for this list? In order of date received. The default sort order provided by the application, to facilitate proper use of the application. Is comparing the rows in the grid by any other method as useful? Does the user need to see the list of messages ordered alphabetically by subject? In these cases where the user is in need of a specific message, searching and filtering is more useful than sorting. The default sort is useful, but allowing the user to resort on the client, in most cases, is not as useful as other methods of finding a row.

Modifying column order and display

The same argument can be made for any of the other methods of customization provided to the end user. Does the user need to reorder or hide columns? The context provided by the application should be sufficient to use the applications data in the way it was intended. Don’t overcomplicate your user interface with needless features or a deluge of useless data. Provide succinct, appropriate data, and the user needn’t reorder or change the interface.

Resizing columns

The default HTML <table> tag expands to fit the data inside of its cells. Even when you set the width of the table explicitly, the cells adjust themselves accordingly to fit the data. This should be the behavior of your table. You needn’t monkey around with widths, the browser is smart enough to do it for you. You can even customize a cell to wrap its text to multiple lines with CSS, if need be.

Editing of row data directly on the grid itself

If you’re providing an Excel spreadsheet interface for the end user to customize your data, you haven’t designed your interface correctly. Rethink how the user needs to interact with the data you’ve provided, and give them a better, simpler way to edit the data.

Scrolling

Everyone knows that internal scrollbars on a page are evil. I don’t even like scrollbars on textareas, to be honest. Previously, I had worked and reworked the YUI DataTable to handle horizontal scrolling. Looking back on this, it was a mistake. There are better ways to handle lots of data in a table, without the heavy mouse interaction and scanning that scrolling require. Which brings me to my next point.

Pagination

This is the one exception to the feature set cutting board. This is the one feature that’s is a requirement, when the data set has too many records to fit on a single page.

Keep these in mind, and look at the feature set provided by a few sites using tabular data centric interfaces that know a thing or two about interface design:

So, what should we include?

A simple CSS class to style your table is sufficient, with links to paginate the table (properly) and/or a hover for row selection if needed. You’re looking at 10-20 lines of jQuery code, maximum, and a few CSS declarations. In lieu of sorting, of course, you’ll need to program in a mechanism for searching and filtering as well. But really, the difficulty with programming this component is knowing what to leave out.

or maybe the same thing using Facelets:

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core">
<body>
<f:view>
<form jsfc="h:form" id="myForm">
<input type="text" jsfc="h:inputText" id="myText"/>
</form>
</f:view>
</body>
</html>


These will both output the following result:

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets">
<body>
<form id="myForm">
<input type="text" id="myForm:myText"/>
</form>
</body>
</html>


Notice how the resulting text field has an ID attribute with the parent id prepended on. Now the real question is, how do we select this result node using the various JavaScript frameworks that are available to us?

Works, but we don’t care: Raw JavaScript or any GetById Function

Obviously using document.getElementById( 'myForm:myText' ); will function correctly. As will any framework that has a similar “GetById” function (YAHOO.util.Dom.get, or $ in Prototype, etc) What is more interesting to us is the behavior using the various CSS selector packages included with each JavaScript library.

Does not work: DomQuery in Ext 1.1 Beta 2

Ext.query( '#myForm:myText' );
Ext.query( '#myForm\:myText' );

These two tests will throw the error Ext.DomQuery.pseudos[name] is not a function, which obviously means that myText is not a pseudo class like :first or :last.

Ext.query( '#myForm\\:myText' );

Throws the error: Error parsing selector, parsing failed at "\:myText"

Works: jQuery 1.1.3

jQuery( '#myForm\\:myText' );

As of version 1.1.3 (the latest of this writing), they have added support for the colon in ID selection when escaped with a double backslash. Versions older than 1.1.3 will not function properly. This is not yet in the documentation but can be viewed in the Escape selectors section of a blog post.

Does not Work: Prototype 1.5.1.1

$$( '#myForm:myText' );
$$( '#myForm\:myText' );

Returns the form instead of the input element and treats myText as a pseudo class.

$$( '#myForm\\:myText' );

Interprets as XPATH selectors (\\ means anywhere in the document), using myText as a pseudo selector now, so it returns ALL nodes in the document.

Does not Work: Dojo query 0.9.0 Beta

dojo.query( '#myForm:myText' );
dojo.query( '#myForm\:myText' );
dojo.query( '#myForm\\:myText' );

It’s becoming mind numbingly obvious that if the framework doesn’t specifically say that you can escape selectors, it’s not going to let you do so. In the first two tests, Dojo performs the same as Prototype. In the double backslash test however, Dojo returns no result nodes.

Does not Work: Mootools 1.11

$$( '#myForm:myText' );
$$( '#myForm\:myText' );
$$( '#myForm\\:myText' );

All throw the error The expression is not a legal expression." code: "51.

There you have it folks. jQuery is the JavaScript library of choice for the discerning JSF applications developer. Kudos to you if you’re already using it.