FineTooth is proud to announce joining the OpenAjax Alliance. A big thanks goes out to Jon Ferraiolo at IBM for getting us involved as well as attempting to organize what is quickly becoming a fragmenting technology. With so many frameworks, so many libraries, and so many vendors – all with different goals and applications – now seems like a very opportune time to try to develop some standards. Hopefully, this will empower future developers to take advantage of the trials and tribulations when considering which patterns or libraries to use in their projects. At FineTooth, we hope to offer some contributions in the Markup and Interoperability Committees. Most of the major software players seem to be throwing some weight into this endeavor too – something that makes us want to have the voice of some smaller development shops heard as the Alliance moves forward..
June 19th, 2006
Author: Lindsey Simon
Two weeks later …
With some tinkering and coding, now I’m really jazzed about the idea of clientside XSLT for widget creation. With Sarissa, it’s not slow at all. Hats off to Manos Batsis for Sarissa, he’s done some really cool work. And for those who want to do it on the server, being able to leverage the exact same code and technique seems really great to me. A dispatcher could even look at the bandwidth of the client and the version of the browser to decide how to optimally deliver the experience. To read about the advantages I see to this approach overall, check out a prior post Google’s AJAXSLT and UI Widgetry Thoughts. I’m getting most of the original DataGrid features working in this XSLT version, so check back as this demo page will get updated. I’d like to offer some profiling statistics too, but even with recordsets of 200 rows, I can barely tell the difference between the Sarissa client-side transform speed and the server/render speed.
References:
The XSL file: XSLDataGrid.xsl
Sarissa
Google’s AJAXSLT
Below is a test page to tinker with:
June 16th, 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…
June 6th, 2006
Author: Lindsey Simon