_fnGetCellData doesn't test for column existence
_fnGetCellData doesn't test for column existence
sebastienbarre
Posts: 24Questions: 1Answers: 0
Hi. Could _fnGetCellData test if a column exists before getting its settings?
The issue is here:
[code]
function _fnGetCellData( oSettings, iRow, iCol, sSpecific )
{
var sData;
var oCol = oSettings.aoColumns[iCol];
var oData = oSettings.aoData[iRow]._aData;
if ( (sData=oCol.fnGetData( oData, sSpecific )) === undefined )
[/code]
This last line is a Javascript error when oCol is undefined, which happens when oSettings.aoColumns[iCol] doesn't exist.
Putting a breakpoint here and looking at the stack trace, it seems to happen when _fnFilterColumn is called but the column the table was filtered on is not in the table anymore (by design, we decided to remove it). The sorting was serialized with the table state and then restored, but the column isn't there anymore.
[code]
function _fnFilterColumn ( oSettings, sInput, iColumn, bRegex, bSmart, bCaseInsensitive )
{
if ( sInput === "" )
{
return;
}
var iIndexCorrector = 0;
var rpSearch = _fnFilterCreateSearch( sInput, bRegex, bSmart, bCaseInsensitive );
for ( var i=oSettings.aiDisplay.length-1 ; i>=0 ; i-- )
{
var sData = _fnDataToSearch( _fnGetCellData( oSettings, oSettings.aiDisplay[i], iColumn, 'filter' ),
[/code]
That last line calls fnGetCellData.
Would you advise a workaround?
Thanks
The issue is here:
[code]
function _fnGetCellData( oSettings, iRow, iCol, sSpecific )
{
var sData;
var oCol = oSettings.aoColumns[iCol];
var oData = oSettings.aoData[iRow]._aData;
if ( (sData=oCol.fnGetData( oData, sSpecific )) === undefined )
[/code]
This last line is a Javascript error when oCol is undefined, which happens when oSettings.aoColumns[iCol] doesn't exist.
Putting a breakpoint here and looking at the stack trace, it seems to happen when _fnFilterColumn is called but the column the table was filtered on is not in the table anymore (by design, we decided to remove it). The sorting was serialized with the table state and then restored, but the column isn't there anymore.
[code]
function _fnFilterColumn ( oSettings, sInput, iColumn, bRegex, bSmart, bCaseInsensitive )
{
if ( sInput === "" )
{
return;
}
var iIndexCorrector = 0;
var rpSearch = _fnFilterCreateSearch( sInput, bRegex, bSmart, bCaseInsensitive );
for ( var i=oSettings.aiDisplay.length-1 ; i>=0 ; i-- )
{
var sData = _fnDataToSearch( _fnGetCellData( oSettings, oSettings.aiDisplay[i], iColumn, 'filter' ),
[/code]
That last line calls fnGetCellData.
Would you advise a workaround?
Thanks
This discussion has been closed.
Replies
Having said that, I can absolutely see that this is a bit of a pain! DataTables 1.10 is going to change the API so you'd do something like `table.column( '{column-selector}' ).filter( '{filter}' )` with the column selector being the column name or column index, and allowing multiple columns to be selected and therefore filtered at the same time. This last part is important since if the selector matches no columns, there is nothing to filter, and no filter is applied.
So yes, something like what you are looking for will be implemented in 1.10, but for the new API rather than the old one.
Thanks for the feedback!
Allan
[/quote]
Yes, which impacts the rest of the page, and prevents the table from rendering correctly.
The issue here is that I've no control over that. The filtering settings is saved automatically when the state of the table is saved (though fnStateSave), which is a feature we like. So if we have somebody in the company filtering on a column and suddenly we (the developers) remove that column from the table, the whole table stops rendering correctly for this guy, and there isn't much we can do. That's why I was suggesting you put an extra safeguard here?
I think the new API with column naming for the column selectors will help, since unknown names will be slightly ignored, but unknown indexes will likely still throw an error.
Allan
Allan
Allan
Allan
I've just committed the required changes into the 1.10 development branch. This is the change set:
https://github.com/DataTables/DataTables/commit/86fd198 .
You might be able to pull the changes into 1.9.4, or you could try 1.10 if you are feeling brave :-). Either way, this change will be in 1.10! Thanks from brining it to my attention!
Regards,
Allan