I just fixed a stupidly obvious bug in liteGrid that shows up when you have multiple grids on a page. Look at the default options for liteGrid:
$.inrad.liteGrid.defaultOptions = { columns: [], dataProvider: new NullDataProvider(), modules: [], missingValue: "", rowIdColumn: "ID", layoutProvider: new BasicLayoutProvider() }
The bug is right there. Keep looking. Give up? Wait, you already see the bug? Crap. Yeah, well, I don’t consider myself a JavaScript expert, and that’s a good example of why.
For those that are like me and didn’t see it, the problem is the use of “new” in the options. What I meant for this code to say was “every liteGrid by default gets a new NullDataProvider and a new BasicLayoutProvider”, but that’s not what that code says. What it actually says is “every liteGrid by default gets a this NullDataProvider and a this BasicLayoutProvider.” That’s right, if you have multiple liteGrids that use the defaults, they will share the layout and data provider. That’s not a problem for NullDataProvider since it doesn’t do anything, but that’s a big problem for BasicLayoutProvider, which handles the rendering and UI for the grid.
I’m not sure what the best option is for handling this. For now, I’ve had the option default to null, and a new BasicLayoutProvider is substituted during initialization, but I don’t like that. I thought about changing defaultOptions to be a method that returned a new object containing the defaults, but then users can’t change the defaults without replacing the entire method. Any suggestions?
What about provider factories?
columns: [],
dataProviderFactory: function(){return new NullDataProvider();},
modules: [],
missingValue: "",
rowIdColumn: "ID",
layoutProviderFactory: function(){return new BasicLayoutProvider();}
Internally, you would just call *ProviderFactory() to get the configured objects.
@Chris,
Man, sometimes I feel really dumb. That’s a perfect solution for this, thanks!