| Page 1 of 1 | [ 4 posts ] |
|
There seems to be a discrepency between how data can be
retrieved from a conventional table column and an inserted column that is added after the DataTable is created. In a inserted column (created through the DataTable.insertColumn() method), a field's value can by retrieved from the Record object for the field's row by calling theRecord.getData( fieldName ); where fieldName is the value of the column's "key" attribute. The value can also be read from the record's _oData array by using the column's index, a integer, as the array index into the array. theRecord._oData[ keyInteger ]; // works but not if the columns key, a string, is used. theRecord._oData[ indexString ]; // returns undefined In a conventional column, added through a column configuration passed to the DataTable constructor, the opposite results are obtained. Calling getData() or reading _oData[keyIndex] returns 'undefined'; reading _oData[fieldName] will return the correct value. The data table's columns appear correct with the inserted column in the set if ones looks at the configurations returned by DataTable.getColumnSet(). This matrix describes the results Code: regular column inserted column This behavior seems inconsistent to me. Is it or am I doinggetData() fails fails _oData[index] fails works _oData[key] works fails something wrong? It seems reasonable to be abled to access the data from either type of column in the same way. A web page demonstration the issue is available at http://pastebin.com/Qq0NWkzj. View it in FireFox using FireBug. Set a breakpoint at the end ShowDataTableValues() to view data values when the button is clicked. Click the other button to insert a column. Thanks in advance for your help. |
|
The confusion comes from using the "field" column definition. You are not calling the original columns "id" and "title" but "0" and "1" because that is what the "field" column property is saying but with the inserted column you are calling it "inSet" since there is no "field". It is just a coincidence that the "0" and "1" column field names match their 0 and 1 (no quotes, they are numbers) position in the record. JavaScript is casting the 0 and 1 to "0" and "1" and that's why you are reaching them.
|
|
Thanks for your reply. However, it still doesn't help me understand why retrieving a cell's value in a 'inserted' column should behave differently than a 'configured' column (where the 'configured' column definition is passed to the DataTable constructor.
I understand that in the later case the 'field' attribute of the column is an index into the data array passed via the DataSource (and is interpreted as an integer). This is distinct from the 'key' configuration attribute which is a string, mutually unique among the columns in the data set. (This is a little confusing in the API docs which use 'sField' as the argument to Record;getData() when getData is looking for a 'key'.) I'm still looking for a way around this difficulty with column types. Practically speaking, I'm looking for a way to iterate over the columns in a table and retrieve their data without having to be aware of the basic nature of the columns. Thanks again. |
|
You should always use getData. In general, object properties starting with an underscore are private and should be avoided.
I can't say much in favor of the field property. It was a late addition and I'm not sure it ever got properly tested under all conditions. It had some bugs and it may still have. If possible, avoid it. Avoid "field", use always "key" and you'll be safe. As for iterating over all fields, use getData without any arguments. That will give you a reference to this._oData. I know, in the end, it is the same thing as accessing _oData but if there was ever going to be any conversion, cloning or whatever, getData would deal with it. Anyway, as things stand, getData and _oData should give you the same results since the code for getData is quite simple: getData : function(sField) { if(lang.isString(sField)) { return this._oData[sField]; } else { return this._oData; } } |
| Page 1 of 1 | [ 4 posts ] |
| You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum |
© 2006-2013 Yahoo! Inc. All rights reserved.
All code on this site is licensed under the BSD License unless stated otherwise.
About This Site · Security Contact Info
Powered by phpBB® Forum Software © phpBB Group