Trying to override fnStateSave; original _fnSaveState still called instead

charles_dyfis_net

Howdy --

I have a requirement that table state (filtering, sorting, etc) be bookmarkable; I'm trying to do this by serializing into the URL fragment. My initial, naive attempt looks like this:

[code]

$(document).ready(function(){
$('#content_table').dataTable({
"bStateSave": true,
"fnStateSave": function(oSettings, oData) {
alert("fnSaveState invoked");
window.location.hash = msgpack.pack(oData);
},
"fnStateLoad": function(oSettings) {
return msgpack.unpack(window.location.hash);
},
});
});

[/code]

However, the provided values "fnSaveState" and "fnStateLoad" implementations are never called, and the original _fnSaveState implementation is invoked instead.

Reading through the DataTables source, for that matter -- it's not obvious to me (as a non-expert in JavaScript) where these would be getting invoked at all, as the original _fnSaveState implementation is directly called from fnSetColumnVis, without any obvious means of allowing a user-provided fnSaveState implementation to be invoked.

Any guidance would be appreciated.

Many thanks for the great software!

allan

The internal function _fnSaveState will always be called, as it is that function which called your "user land" function :-) There is no method of overriding this behaviour, but certainly fnStateSave should be called, as it is in this example: http://datatables.net/beta/1.9/examples/advanced_init/localstorage.html . Can you confirm that you are using DataTables 1.9? Can you run your table through the debugger please ( http://debug.datatables.net )?

Allan

charles_dyfis_net

...well, my face certainly is red -- indeed, I was using a 1.8-series release. Thanks!

For the benefit of anyone reading this who's interested in accomplishing something similar, the following code is what I ended up using to store the table's state in the URL fragment (compressed with msgpack and base64-encoded; while the base64-encoding loses much of msgpack's space advantages, it's still a full 1/3 smaller than the expanded JSON content). Note that IE compatibility would require using a native javascript base64 library rather than using atob() and btoa():

[code]
"fnStateSave": function(oSettings, oData) {
window.location.hash = btoa(msgpack.pack(oData, true));
},
"fnStateLoad": function(oSettings) {
fragment = window.location.hash
if((fragment != null) && (fragment.length > 1)) {
return msgpack.unpack(atob(fragment.substring(1)));
}
return null;
},
[/code]

...the above is known to work both on Chrome and Firefox; the msgpack javascript library is from https://github.com/msgpack/msgpack-javascript