Google’s AJAXSLT and UI Widgetry Thoughts

June 6th, 2006 Author: Lindsey Simon

I’ve recently spent a little time tinkering with Google’s JavaScript XSLT library. It is available online at: goog-ajaxslt.sourceforge.net. I started to wonder if client-side XSLT would be one cool way to implement the OpenRico LiveGrid’s and/or my DataGrid’s functionality to xhtml tables. One of Richard’s goals for the OpenRico project is for it to be able to “fail gracefully” – in other words, to not be crippling to roll back out of; this is a principle I like too. The idea of taking a semantically correct representation of tabular data and then “live-ifying” it, and or adding certain kinds of dynamic functionality(reorderable columns, resizable columns, etc…) to it, is very, very appealing to me – an analogy being something like a taking a house frame and building everything else on top of and into it – and being able to go, “You know what, I don’t need a bathroom!” and voila, you can lose it and use that space for something else. Google’s XSLT via JavaScript/DOM looks like it will be too slow to do what I want, but it is a neat approach, at least in theory.

Why not CSS only?
One of the classic problems with tables is trying to achieve the scrolling table-body. It has been done with some quirky looking CSS (mostly for IE’s sake) but a CSS-only approach will never achieve some of the functionality I crave in a table beyond scrollability. (Until XForms – jk)

Why not DOM then?
So introducing a slew browser-centric CSS selectors doesn’t appeal to me if DOM manipulation can achieve the same thing more simply. Derek Anderson has created a nice demo of this approach. I think the Google AJAXSLT approach might offer a clean way of doing what Derek did, but what if you want all the extra bells and whistles? DOM just seems too slow – and Google’s AJAXSLT seems too slow (it also being an interface to browser DOM). You can see a test of a really simple table with like 100 rows being rewritten into two tables ala our DataGrid here.

So what then?
I don’t believe that it’s using Java to produce JavaScript! Currently, at FineTooth, we’re writing dynamic Smarty templates with inline functionality and using Ajax to completely repopulate container divs with the template-driven XHTML – basically bypassing all DOM interaction for setup, but using and relying on DOM for interactivity. This approach works for us now, but if we stopped using PHP or Smarty, we’d have to reimplement things. I’m going to check out Protowidget, but I’m already not a fan of its syntax – “leveraging custom attributes in order to do all of the wiring”. I guess I have this aversion to repurposing structural tags (anchors as buttons, spans as text) – but perhaps I’m just being semantically snotty. Server-side XSLT is an approach I’m looking into. I’d like to be able to produce these widgets somewhat server-agnostically, or at least have very similar implementations for ASP, Ruby on Rails, PHP, etc.. I’d rather not have the Rails way and an ASP way that looked totally foreign to one another. The hunt goes on then…

Entry Filed under: User Interface