I just committed a major change to liteGrid. Prior to this change, liteGrid’s core was responsible for most of the table rendering. It would render a basic table with a header and no rich-UI functionality. All the niceties (resizable columns, jQuery UI integration, fixed header row) were added by the LayoutManager module. This worked, but required a few ugly hacks, such as shifting the table behind the fixed header row. It also introduced some module-to-module coupling issues that I didn’t like. Some modules (such as the sortable columns one I’m working on) really need to know about the rich UI added by the LayoutManager module. I solved part of this by migrating some things, like the jQuery UI placeholders, into liteGrid’s core, but that never felt like the right solution to me.
Changing gears for a second, I always envisioned basically three ways to extend liteGrid. The first is obvious: the add-on modules. The second is providers that could be plugged in. The third is by replacing built-in methods with your own.
Providers are different from modules in that they are *required* for liteGrid to function, they have a fixed spec that they must implement, and modules can reference them because they are guaranteed to be there. Originally I had envisioned a format provider in addition to the data provider that exists today, but I ended up scraping it. So prior to today, there was only a single provider slot (the data provider).
Back to today’s changes: liteGrid now has a second provider that handles the layout of the grid. That’s right, liteGrid core now contains now rendering logic. It stubs out the rendering methods with exceptions (so that developers will get a more useful error message if they fail to implement a layout provider correctly), but it defers all the rendering to the configured layout provider. The default provider replaces the LayoutManager add-on and includes resizable columns, a fixed header row, etc. Since it has complete control over the markup that’s rendered, it also removes a few ugly IE-specific hacks, and makes it easier to add sorting to liteGrid.
Another cool thing about switching to a provider model is that you can now fully control how liteGrid is rendered (though there might still be a few modules that need to be updated to make this statement completely true). Want to render it as a bunch of nested <div> elements? Go right ahead. Want to spit it out as an unordered list? That’s doable, too.