jQuery UI Grid And OData

The jQuery UI grid widget has yet to see the light of day.  Even though it's still a work in progress, things are looking very positive.  Earlier on in the jQuery UI grid development, I wrote about the zero-feature grid — one in which the grid data is based on the traditional HTML table.  The difference, of course, is that jQuery UI widgets embellish the markup and add CSS classes from the theme framework.

But any grid widget will have to be slightly more effective at retrieving data — more efficient.  The zero feature grid is meant as a starting point from where we can transition our existing HTML table structures into grid widget.  Once the grid widget is ready for a future release, we'll be in for a nice surprise — a standardized method of passing data to our grids.

JSON is almost a standard
For a grid widget to display our data, it needs to retrieve it from the application server somehow.  The traditional, legacy approach is to embed the data inside the presentation structure itself — as is typical of HTML tables.  There are a couple obstacles to overcome, however.  For one, you can't use any APIs you've built for your application — unless they're returning data in HTML table format — unlikely.  So, what is an alternative?  Our widget is probably going to require some other form of markup — one better suited for transferring data — not data lodged inside of presentation markup.

That sounds easy enough — all we have to do is implement our API URIs — each returning a JSON response.  So, in the case of a grid widget, it simply makes an API request for a list of JSON objects to display in the grid.  With this approach, our user interface can share data access patterns — the API — with other third-party applications.  Also, we're no longer obligated to return data that conforms to specific user interface idiosyncrasies.  At least in theory, that's what we've achieved with the JSON approach.

In practice, however, you can't escape at least some level of coupling between the user interface and the API supplying it with data.  The user interface has to know what to expect from the API — what format is being returned, what the object representations look like.  Or, perhaps you've already designed a widget that you want to use for a new API.  In this case, your user interface has a direct impact on the API design.  So you might be making prodigal compromises in both the user interface and the API.

The problem underscored when building custom APIs that support reuse with widgets is a perplexing task.  Having at least a small set of common functionality is possible with the help of JSON — but it isn't exactly a standard — it's more of an informal notation.  Powerful as JSON is as a lightweight tactic for  transferring data over the wire — it doesn't help our standards within applications.

OData is a standard
The OData — Open Data Protocol — aims to solve some of the problems inherent with trying to use the same data set with different widgets or to create new APIs for existing widgets.  Aside from the JSON format itself, one problem with the ad hoc RESTful JSON APIs we've seen is that their resource URI's aren't consistent.

Another issue, one that more closely relates to the run time of the client code itself, is that of sorting and filtering data.  Sometimes, with large data sets, it is either impractical or impossible to do this locally on the client hardware.  So the API must offer the client a means to specify what filtering must take place before the actual data is returned.  Again, this is difficult to be consistent with simply because we've now got to reach a consensus on how these arguments are passed to the listing resource.  There is more than one way to do these things, and I'm not sure there is any merit in contemplating the correct way unless it is stated outright in the standard.

Specifying data transformations consistently is a key issue that OData attempts to solve for applications that implement it.  We have a standardized, methodical approach to asking for the specific data we need.  With that in mind, we can go about designing our widgets around the data they're expecting to see because we have a general idea of how to ask for it.

Almost like streaming media
Based on the examples I've seen so far that highlight the jQuery UI grid widget — still under heavy development — it appears as though the grid has the potential to behave like a media player.  Instead of binary video data being sent to the Flash or HTML 5 video element, the widget can display semantic application data.  The amount of effort required by the developer to make this a reality is negligable — especially if the application is already utilizing OData.

Now here is the really fun part.  Also like media elements, you can point your jQuery UI grid data source to a third party service that implements OData.  The example OData jQuery UI grid retrieves a list of titles from the Netflix API.

We'll still have to wait and see what the finished product looks like some solid design decisions are being fulfilled.  The grid, use in an OData source as it's input stream, is like a flexible "data player".