byuva
10-06-2006, 02:21 PM
At a conceptual level I am struggling with the positional nature of the data model. I like the recent change to add a "dataIndex" parameter to the column model but wonder if we could take it a step further.
cm = new YAHOO.ext.grid.DefaultColumnModel([{
header: "Common Name",
width: 155,
dataIndex: "name"
}]);
I like to view data in a SQL or object oriented perspective where a row/object has named attributes and types. Viewing the attributes as ordered or positional seems to create a potential maintenance nightmare (what happens if you remove a column, not only do you have to change all references to it but you have to decrement all numbered refences above it).
My naive solutions to add two private associative arrays to the abstract data model (or default?). We can still store the data the same way (no point in making an array of associative arrays) but create a lookup that simply maps each field name to its positional column. If no field names are passed to the constructor we can simply associate the column number <int> with the corresponding column (ie all of our methods that have been taking <int> should still work the same now that they take <hashable>). I also think another array that would associate each column with a type <string> would be helpful. The column model could use this to default sort, render and edit behavior.
Does this make sense? Are there advantages to using <int> access to the data?
-brian
cm = new YAHOO.ext.grid.DefaultColumnModel([{
header: "Common Name",
width: 155,
dataIndex: "name"
}]);
I like to view data in a SQL or object oriented perspective where a row/object has named attributes and types. Viewing the attributes as ordered or positional seems to create a potential maintenance nightmare (what happens if you remove a column, not only do you have to change all references to it but you have to decrement all numbered refences above it).
My naive solutions to add two private associative arrays to the abstract data model (or default?). We can still store the data the same way (no point in making an array of associative arrays) but create a lookup that simply maps each field name to its positional column. If no field names are passed to the constructor we can simply associate the column number <int> with the corresponding column (ie all of our methods that have been taking <int> should still work the same now that they take <hashable>). I also think another array that would associate each column with a type <string> would be helpful. The column model could use this to default sort, render and edit behavior.
Does this make sense? Are there advantages to using <int> access to the data?
-brian