bStateSave breaks bVisible
bStateSave breaks bVisible
pluggy13
Posts: 3Questions: 0Answers: 0
Hi,
I believe I have found a bug in your (otherwise excellent!) datatables plugin:
I have a table which should display 4-5 columns, depending on the data in the database. I am using the bVisible flag on one of the columns to hide or show the column accordingly when the page is reloaded.
Now when I also ads bStateSave:true to the table, load the page and then change my data so that the number of columns should change, then reload the page, the new value of bVisible is ignored. If I delete the cookie and then reload the page, everything works as expected (the number of columns changes).
In other words, it appears that the cookie set by the bStateSave:true option assumes that the table definition will not change. When it does change, the new settings are ignored. Instead, it appears that the old definition from the cookie is used. This is of course what you would want for the sorting options, but it seems to me that some other options (such as bVisible) should not be cached in the cookie.
Is this a bug or a feature I am misunderstanding?
Thanks,
Adrian
I believe I have found a bug in your (otherwise excellent!) datatables plugin:
I have a table which should display 4-5 columns, depending on the data in the database. I am using the bVisible flag on one of the columns to hide or show the column accordingly when the page is reloaded.
Now when I also ads bStateSave:true to the table, load the page and then change my data so that the number of columns should change, then reload the page, the new value of bVisible is ignored. If I delete the cookie and then reload the page, everything works as expected (the number of columns changes).
In other words, it appears that the cookie set by the bStateSave:true option assumes that the table definition will not change. When it does change, the new settings are ignored. Instead, it appears that the old definition from the cookie is used. This is of course what you would want for the sorting options, but it seems to me that some other options (such as bVisible) should not be cached in the cookie.
Is this a bug or a feature I am misunderstanding?
Thanks,
Adrian
This discussion has been closed.
Replies
Thanks,
Adrian
This is an interesting one! The offending line of code which is causing the behaviour that you are seeing is:
[code]
if ( typeof oInit.saved_aoColumns != 'undefined' && oInit.saved_aoColumns.length == iLen )
[/code]
in the main initialisation. Removing the second half of that condition and then adding another one inside the loop to check that the array index you want to read, and the column, are available would do what you are looking for.
However, I hesitate to make this change as the majority of the time when the columns for the tables change the whole table has changed completely. Also, the column marking works on an index basis, so the situation could arise whereby the column the user marked as hidden before is now not longer hidden, but a different one is, after a reload.
So this is currently working as intended. The question is if that intended behaviour is correct or not...
Allan
--Adrian
Allan
We just ran into this issue today and we really would like to use the state save. What's the status of this issue?
Allan
Instead of index, could this be done based on class? Currently we can pass in a class name in aTargets. I was thinking if ColVis could use class name instead of index, and that be state saved, it could potentially solve the problem. Of course I didn't think this through a whole lot, was just the first idea that came to me.
My use case is that I use server side processing (via Django) to tell if a user is authenticated or not and then show an additional column.
So, if a user views the table as a generic user, then logs in to gain elevated permissions, the table still shows as before.
One easy/hack solution may just be to wire up a button to "hard refresh" the table and delete cookies in the process. Doesn't seem particularly user friendly, especially in the case where the user may not know that they are missing data.
Since my example is not quite as dynamic as the others, I can probably delete the datatable cookies at login/logout.
Update: here is my fix. My rationale is that column visibility (in our application) can only be changed by the user if the ColVis plugin is in effect. Therefore, I use the fnStateLoadParams callback to see if the table is using ColVis. If it is not using it, then I empty the abVisCols variable in the state, so that the visibility of the columns is never changed. Something like that:
[code]
myloadStateParams = function (oSettings, oData) {
if (oSettings.sDom.indexOf('C') === -1) {
oData.abVisCols = [];
}
};
options = {
'iDisplayLength': 25,
'sPaginationType': 'full_numbers',
'bAutoWidth': false,
'bServerSide': false,
'fnStateLoadParams': myloadStateParams,
};
[/code]
Allan
I modified your example and you see, this does'nt work:
http://live.datatables.net/atewig/4/edit#javascript,html,live
greets
allan,
What is the fix, can i try it on my projet?