User provided properties on row object is not available during a filter.
User provided properties on row object is not available during a filter.
Jeach
Posts: 5Questions: 0Answers: 0
I can't really report this as a 'bug report', but it's causing us some major headaches.
I had originally posted a question on StackOverflow, hoping to get user help or guidance. Then I realized that it was the behavior of DataTables that wasn't consistent when filter was applied to a table.
You can read the SO post here:
http://stackoverflow.com/questions/13180260/identifying-filtered-rows-with-datatables/13181729#13181729
Here is a description of the problem. When I populate a table, our own database records don't necessarily match the row number, especially when a table is filtered. I noticed that in our code, the original programmer simply inserted an 'ID' property to the 'rowData' as to bind our own record ID for future use.
Example: Populates the data table
var rowPos = mainTable.fnAddData(tableData, false)[0];
var rowData = mainTable.fnSettings().aoData[rowPos];
$(rowData.nTr).attr("id", "UID" + id); // Since the id doesn't always match the row
rowData.ID = id;
As expected, the 3rd row does nothing because the actual element does not exist in the DOM at this time. When I set the second argument of 'fnAddData()' to 'true' it then works fine. But due to huge performance issues, we must keep the table add to 'false'.
The original programer added some logic within the 'fnRowCallback()' function to add our 'id' attribute to the of each row, such as the following example:
var id = mainTable.fnSettings().aoData[tablePos].ID;
$(row).attr("id", "UID" + id); // Since the id doesn't always match the row
And this seems to work fine, so long as no table filter is applied. Although its repetitive work each time this callback gets called. But I found no other way to do this during the table populate operation.
We noticed that our web application basically had major bugs when the client applied a filter to the table. After inspection, I realized that when a filter is applied, the 'ID' property seems to be 0 (and 1, 2, etc if many rows are in the table after the filter is applied).
The issue is that the 'ID' should not start with 0 and be sequential, but rather it should be what it was set to during the table populate operation.
Example:
If I add 5 rows to a table, during my loop, I add my rows to the table as usual. If I were to set 'rowData.ID = myID + 100', everything seems to work well and in the 'fnRowCallback()' the 'ID' property is as expected. I can navigate the pages and the 'ID' is always what I expect. But when I apply a filter to limit to 2 records (3 first filtered out), I expect to have 'rowData.ID' be 102 and 103. But it's always the very first value (100 and 101).
So when someone clicks on the link or icons of a filtered table, my event handling functionality operates on the wrong records.
Please let me know if you need further details or any information.
I had originally posted a question on StackOverflow, hoping to get user help or guidance. Then I realized that it was the behavior of DataTables that wasn't consistent when filter was applied to a table.
You can read the SO post here:
http://stackoverflow.com/questions/13180260/identifying-filtered-rows-with-datatables/13181729#13181729
Here is a description of the problem. When I populate a table, our own database records don't necessarily match the row number, especially when a table is filtered. I noticed that in our code, the original programmer simply inserted an 'ID' property to the 'rowData' as to bind our own record ID for future use.
Example: Populates the data table
var rowPos = mainTable.fnAddData(tableData, false)[0];
var rowData = mainTable.fnSettings().aoData[rowPos];
$(rowData.nTr).attr("id", "UID" + id); // Since the id doesn't always match the row
rowData.ID = id;
As expected, the 3rd row does nothing because the actual element does not exist in the DOM at this time. When I set the second argument of 'fnAddData()' to 'true' it then works fine. But due to huge performance issues, we must keep the table add to 'false'.
The original programer added some logic within the 'fnRowCallback()' function to add our 'id' attribute to the of each row, such as the following example:
var id = mainTable.fnSettings().aoData[tablePos].ID;
$(row).attr("id", "UID" + id); // Since the id doesn't always match the row
And this seems to work fine, so long as no table filter is applied. Although its repetitive work each time this callback gets called. But I found no other way to do this during the table populate operation.
We noticed that our web application basically had major bugs when the client applied a filter to the table. After inspection, I realized that when a filter is applied, the 'ID' property seems to be 0 (and 1, 2, etc if many rows are in the table after the filter is applied).
The issue is that the 'ID' should not start with 0 and be sequential, but rather it should be what it was set to during the table populate operation.
Example:
If I add 5 rows to a table, during my loop, I add my rows to the table as usual. If I were to set 'rowData.ID = myID + 100', everything seems to work well and in the 'fnRowCallback()' the 'ID' property is as expected. I can navigate the pages and the 'ID' is always what I expect. But when I apply a filter to limit to 2 records (3 first filtered out), I expect to have 'rowData.ID' be 102 and 103. But it's always the very first value (100 and 101).
So when someone clicks on the link or icons of a filtered table, my event handling functionality operates on the wrong records.
Please let me know if you need further details or any information.
This discussion has been closed.