Please help me migrate from "fnStateLoadCallback"
Please help me migrate from "fnStateLoadCallback"
Artem
Posts: 4Questions: 1Answers: 0
Hi!
I used DataTables 1.8 and have tried to upgrade to new 1.9 recently. Could you please help me to update my code in consistence with new state saving API?
I want to save everything besides search (filtering) values - neither for common "Search" field, nor for individual columns. To achieve that I did the following with 1.8:
[code]
$('#example').dataTable({
bStateSave: true,
fnStateLoadCallback: function( oSettings, oData ) {
oData.sFilter = '';
for (var i = 0; i < oData.aaSearchCols.length; i++)
oData.aaSearchCols[i][0] = '';
return true;
}
});
[/code]
So, I just clear all saved search values on their reloading. What is the best way to lost them using new API in 1.9?
Thank you,
Artem
P.S. I need to say your project is great - DataTables has rich but easy-to-use functionality and saved me a lot of time on various projects.
I used DataTables 1.8 and have tried to upgrade to new 1.9 recently. Could you please help me to update my code in consistence with new state saving API?
I want to save everything besides search (filtering) values - neither for common "Search" field, nor for individual columns. To achieve that I did the following with 1.8:
[code]
$('#example').dataTable({
bStateSave: true,
fnStateLoadCallback: function( oSettings, oData ) {
oData.sFilter = '';
for (var i = 0; i < oData.aaSearchCols.length; i++)
oData.aaSearchCols[i][0] = '';
return true;
}
});
[/code]
So, I just clear all saved search values on their reloading. What is the best way to lost them using new API in 1.9?
Thank you,
Artem
P.S. I need to say your project is great - DataTables has rich but easy-to-use functionality and saved me a lot of time on various projects.
This discussion has been closed.
Replies
Absolutely! The code needed for the updated API is actually very similar to what you already have:
[code]
$('#example').dataTable({
bStateSave: true,
fnStateSaveParams: function( oSettings, oData ) {
oData.oSearch.sSearch = '';
for (var i = 0; i < oData.aoSearchCols.length; i++) {
oData.aoSearchCols[i].sSearch = '';
}
}
});
[/code]
I've use fnStateSaveParams (rather than the loading equivalent) since there is little point in storing information in a cookie to then throw it away. Also The full filtering object is now saved, hence the need to use the sSearch parameter from the search object.
And that should be it :-)
Regards,
Allan
Thank you so much! It works great now. And yes, you are right about losing unnecessary data before save it rather then after load. :)
Just in case you will find something useful from my experience of DataTables usage let me please briefly describe how I'm using it (just skip this part if not interested ;).
I'm trying to use DataTables in my own OpenSource project, which has a lot of data displayed as a table. DataTables made a lot of work for me (like paging, multicolumns sorting, state saving, filtering by columns, and server-side processing). But there were a couple of things which didn't work "out of box" as I need them to work:
1. I wanted an ability to filter one column by entered text and another column by value from dropdown list. At the moment it's needed to code separately.
2. When filtering by column and having server-side processing, the server-side script is bothered immediately after each change in the filter box, so when I type "artem" (5 chars) to filter data, the server-side script is bothered 5 times! For huge datasets (which are usually the reason for server-side processing being turned on) this consumes too much processing time on a server. So I made 0.5 second delay between typing and call to server-side script; the script is executed only when it seems a user has stopped to type.
If you would like, you may check how both things work on this live example (the link is removed because it was a temporary one). It's a mock-up with hardcoded data, so you can do there what you want. And if this inspires you to extend DataTables or append the documentation with another example, I will be happy to share the code.
Best regards,
Artem
Thanks very much for the feedback - much appreciated!
> 1. I wanted an ability to filter one column by entered text and another column by value from dropdown list. At the moment it's needed to code separately.
The fnFilter API method is provided to allow access to the filtering controls that DataTables has, and I presume you ended up using that. However, presenting filtering controls for individual columns, and in different ways, would add a lot of weight to DataTables core, and I want to keep the software as slim as possible. It sounds ripe for a plug-in thought!
> 2. When filtering by column and having server-side processing, the server-side script is bothered immediately after each change in the filter box
Have a look at this plug-in ( http://datatables.net/plug-ins/api#fnSetFilteringDelay ) which introduced a key debounce to address this issue.
Very interesting to hear and see how you are using DataTables! Feedback on features and usage is very welcome indeed!
Regards,
Allan
[quote]The fnFilter API method is provided to allow access to the filtering controls that DataTables has, and I presume you ended up using that. However, presenting filtering controls for individual columns, and in different ways, would add a lot of weight to DataTables core, and I want to keep the software as slim as possible. It sounds ripe for a plug-in thought![/quote]
Yes, I did it via "fnFilter". I understand your point about weight of the DT core and completely agree. I mentioned this use-case because I found it requires to write quite a lot of code to implement it via "fnFilter", so I think you are right saying that it could be another plugin. Maybe I will create one later. :)
[quote]Have a look at this plug-in ( http://datatables.net/plug-ins/api#fnSetFilteringDelay ) which introduced a key debounce to address this issue.[/quote]
Thank you for the hint - this plugin seems to be what I was looking for!
Best regards,
Artem