Bug when using custom sSortDataType
Bug when using custom sSortDataType
stotten
Posts: 4Questions: 0Answers: 0
I believe either the examples for sSortDataType are wrong or there is a bug, however it seems that if I use a custom sorting preprocessor the value returned in the array can be written into the wrong aoData location.
I believe the sort handler should take as input the data in the order it is presented in the table (i.e. using a DOM query such as
[code]$( 'td:eq('+iColumn+')', oSettings.oApi._fnGetTrNodes(oSettings) ).each( function () { ... } )[/code]
However this results in the datatables library writing the returned value into the location at
[code]_fnSetCellData( oSettings, j, iColumn, aData[j] );[/code]
If my data is already sorted (ie I've clicked sort already), then subsequent calls to the sort handler will result in the above "j" writing to the wrong location, i.e. as if my sSortDataType was querying the original unsorted data.
I believe the fix for this is to change the above _fnSetCellData call to
[code]_fnSetCellData( oSettings, oSettings.aiDisplayMaster[j], iColumn, aData[j] );[/code]
This takes the sorted order into account. An alternative fix would instead be to insist that all sSortDataType implementations instead sort the data based upon aoData (e.g. using_fnGetCellData) - this would then always use the original unsorted data rather than the displayed data.
An example of the bug can be seen at http://jsfiddle.net/knChb/1/
I believe the sort handler should take as input the data in the order it is presented in the table (i.e. using a DOM query such as
[code]$( 'td:eq('+iColumn+')', oSettings.oApi._fnGetTrNodes(oSettings) ).each( function () { ... } )[/code]
However this results in the datatables library writing the returned value into the location at
[code]_fnSetCellData( oSettings, j, iColumn, aData[j] );[/code]
If my data is already sorted (ie I've clicked sort already), then subsequent calls to the sort handler will result in the above "j" writing to the wrong location, i.e. as if my sSortDataType was querying the original unsorted data.
I believe the fix for this is to change the above _fnSetCellData call to
[code]_fnSetCellData( oSettings, oSettings.aiDisplayMaster[j], iColumn, aData[j] );[/code]
This takes the sorted order into account. An alternative fix would instead be to insist that all sSortDataType implementations instead sort the data based upon aoData (e.g. using_fnGetCellData) - this would then always use the original unsorted data rather than the displayed data.
An example of the bug can be seen at http://jsfiddle.net/knChb/1/
This discussion has been closed.
Replies
Allan
The JSFiddle link I included in the original post should show this issue - if you run this and sort by the first column the first time it works (as the displayed data and sorted data are in the same order), but subsequent sorts start getting out of order.
Please let me know if you have any issues.
Thanks
[code]
$( 'td:eq('+iColumn+')', oSettings.oApi._fnGetTrNodes(oSettings) )
[/code]
Gives the nodes in the order of the document - not the original array, which is what we want.
This is a change to use $.map which addresses the issue:
http://jsfiddle.net/knChb/2/
Allan