column.data vs mData differences

ndotz

Recently began updating some legacy code from 1.9.4 to 1.10.1 and had an issue with some custom column definitions.

Previously the data function would fire with type 'set' on table load and I was using it to place a custom object in the column based on other column values.

However, in the new version it appears that that the 'set' type is only used when explicitly setting a cell value - therefore only the defaultContent would show or it would be undefined and I would receive the "Warning: Requested unknown parameter '{function}'" error described Here

To resolve the issue I explored

1. column.render - But this does not appear to be an option as the return of the object is necessary for click handlers
2. Making the returns dynamic rather than rely on an initial "set" as seen below. This works, but my concern is whther there is a performance impact using this method -- which documentation of column.data would lead me to believe is the case "Store the computed dislay and filter values for efficiency"

Is there some way to (that I appear to be missing) to return the former functionality or is there a better way to accomplish this?

Thanks in advance!

function cgFormLink(column, list) {
    var mappedName = column.mappedName;
    return {
        'data': function (data, type, val) {                            
                if (type === 'set') {
                    data[mappedName] = {
                        text: !val ? setText(column, data) : val,
                        displayIcon: setIcon(val, column.displayIcon),
                        listName: !column.form.list ?  list : column.form.list,
                        formView: !column.form.view ? '' : column.form.view,
                        formType: !column.form.type ? 'edit' : column.form.type,
                        formQueryString : !column.form.queryString ? 'ID' : column.form.queryString,
                        itemId: !val ? setId(mappedName, data) : val,
                        listType : !column.Form.listType ? 'Task' : column.Form.listType
                    };
                    data[mappedName + '_display'] = data[mappedName]['displayIcon'] ? data[mappedName]['displayIcon'] : data[mappedName]['text'];
                    data[mappedName + '_filter'] = data[mappedName]['text'];
                    data[mappedName + '_sort'] = data[mappedName]['text'];
                    return null;
                } else if (type === 'display') {
                    return data[mappedName + '_display'];
                } else if (type === 'filter') {
                    return data[mappedName + '_filter'];
                } else if (type === 'sort') {
                    return data[mappedName + '_sort'];
                }
                return data[mappedName];
        },
        'className': 'FormLink'
    }
}

vs

function cgFormLink(column, list) {
    var mappedName = column.mappedName;
    return {                    
        'data': function (data, type, val) {                            
                if (type === 'set') {
                    data[mappedName] = val;
                    return;
                } else if (type === 'display') {
                    return getIcon(val, column.displayIcon);
                } else if (type === 'filter') {
                    return getText(column, data);
                } else if (type === 'sort') {
                    return getText(column, data);
                }
                return {
                        text: getText(column, data),
                        displayIcon: getIcon(val, column.displayIcon),
                        listName: !column.form.list ?  list : column.form.list,
                        formView: !column.form.view ? '' : column.form.view,
                        formType: !column.form.type ? 'edit' : column.form.type,
                        formQueryString : !column.form.queryString ? 'ID' : column.form.queryString,
                        itemId: getId(mappedName, data),
                        listType : !column.form.listType ? 'Task' : column.form.listType
                };
        },
        'className': 'FormLink'
    }
}

allan

Hi,

Thanks for the bug report. I've just put a little test case together for this: http://live.datatables.net/cuciyihi/1/edit .

I think this is a bug - let me get back to you when i've had a chance to investigate a bit more.

Allan

ndotz

Thanks!

Was looking at _fnAddData and there may be a missing type parameter in the call to _fnGetCellData or an initial call to set prior to setting cell data. Haven't had a chance to test out yet though.

line 1005: _fnSetCellData( oSettings, iRow, i, _fnGetCellData( oSettings, iRow, i ) );

line 1085: _fnGetCellData( settings, rowIdx, colIdx, type )

allan

Hi,

I've just been looking into this and the change in 1.10 is actually intentional as was part of the work of removing the old fnRender option. Basically the columns.data option is called as a setter when a new row is added only when the data for the row is sourced from the DOM (i.e. the tr element exists already).

The idea was that if that is not true, then the data is being sourced from Javascript in some way (Ajax for example) so I assume that the data will already be in the format required. The reason for this is that if a setter is always called on every cell, even when the data being set is the same then there is a significant performance penalty. It may also break references if the data is sourced from an object instance.

So I'm afraid, the answer is not what you want to hear - this is a backwards incompatibility with 1.9-. I've added a note to the documentation here to explain the use of the setter.

Regards,
Allan