Improvements in Cookie-Handling

John Archer

Hi Allan,

I have two suggestions regarding cookie handling, as I begin to use it now in order to load and store the cookie on a server, if it is not existing for a specific user in the browser/current session:

1. It is great to modify the prefix through 'sCookiePrefix'. Would it be possible to add one/two new parameter to also modify the _suffix_ and/or the complete cookie name? I makes programming life a little bit harder to hardcode for example the "_index.php" suffix all the time. Would be nice to have it configurable, too.

2. It took me some time to recognize that fnStateLoadCallback is just called, if the correct cookie is already there! In my plans I wanted to use fnStateLoadCallback to check, whether the cookie is there and if not, then grab it from the remote data server. Unfortunately that does not work and I have to do a workaround, which is not so perfect IMHO. Is it possible to change the behaviour that way, that fnStateLoadCallback is _always_ called when bStateSave is true? Would help a bunch!

Thanks a lot!

Regard!

allan

Hi John,

Thanks very much for the feedback!

1. Would it not be possible to just put the "_index.php" in the prefix? It does mean that the cookie name is less human readable, but it also means one less configuration parameter, with the same functional result perfectly possible :-)

2. That is an excellent point. fnStateLoadCallback, was implemented to be a post processing event - i.e. you can manipulate what was in the cookie, but that doesn't help much if you are not using the cookie... Let me think about this one a little bit and get back to you if that is okay. I've trying to wrap up 1.9beta1 development at the moment, so I will look at this with a view to getting it into the beta.

Allan

allan

Hi John,

I've just committed a change to the 1.9 development branch which will fire the state loading callback regardless of the cookie state. It is just a rearrangement of the code, rather than anything particularly new - you might now get null in the callback though rather than an object from the cookie.

You can grab the latest 1.9 development software from here: https://github.com/DataTables/DataTables/blob/1_9_DEV/media/js/jquery.dataTables.js

Allan

John Archer

Hi Allan,

thanks a lot for your quick response - and for you quick update (so cool!)! I will have a look at it later.
Point 2 is great, and I will test it in the development branch.

Concerning point 1: I am not sure whether this would be so good, especially as I use more than one DataTable (therefore more than one DT cookie) on the site. Right now my default cookie name is [code]SpryMedia_DataTables_entitytable_index.php[/code]. I set sCookiePrefix to [code]username + '_' + classname + '_'[/code] so I get e.g. [code]Archer_Tasks_entitytable_index.php[/code]

Oh, thinking while writing maybe your solution would be indeed perfect! Would the result of your suggestion in the default behaviour be [code]SpryMedia_DataTables_index.php_entitytable[/code]? So 'entitytable' (the name of the table) would still be there? Then it would be really great (so I would get rid of the 'index.php' string) and achieve a better cookie name like [code]Archer_Tasks_entitytable[/code]!?

That would be perfect! :-)

I will test the code later and get back to you.

Thanks a lot!

allan

Hi John,

It is actually possible to have complete mastery of the DataTables cookie name at the moment, through the use of the fnCookieCallback function: http://datatables.net/usage/callbacks#fnCookieCallback . With that function (as you'll see in the example) you control the name and the contents of the cookie completely, so you could do it that way. The only disadvantage is that it is a little bit less elegant that having DataTables do the whole thing for you!

Allan

John Archer

Hm ... I have to think about it a bit ... But fnCookieCallback is fired _after_ Load and Save, I think that could lead into some trouble for me!? Hm, not sure ... But thanks again!

John Archer

Yay, your change with fnStateLoadCallback in the dev branch works like a charm, thanks a lot!

Unfortunately my project does not load correctly anymore with the dev version. Maybe there are some API changes in the new version? Have to look it up, no worries for you.

What is the timeframe for releasing 1.9?

Thanks a lot!

Cheers!

allan

In theory there shouldn't be any API changes, but I have made large internal changes, so it is entirely possible that I've broken something. I discovered yesterday that I had broken API plug-ins for example (they work again now).

What appears to be broken? There should be only want backwards incompatible change, which is to change to using A tags for the pagination rather than SPAN/DIV tags (and that's only a styling issue). Anything else is a bug!

> What is the timeframe for releasing 1.9?

I hope to have a beta next week - I've just got one more thing I want to get sorted out - better accessibility support. That's a little opened ended though since I am far from an expert in that area... But, the plan is beta next week and final release in January.

Allan

John Archer

Sorry for my late response, didn't work at weekend.

I have to do a little JS debugging now (as Firebug gives me now error, but there must be something). I will get to you soon.

Thanks a lot for sharing your time frame! I do look forward to the release!

John

John Archer

Ok, I know a little bit more now.

I use a quite heavily customized/extended fnServerData callback. There, I also extended the $.ajax success handler. So in my project it looks like this:

[code]"success": function(result)
{
fnCallback(result);

// here comes many custom stuff
}
[/code]

This works great in DT 1.8.2 but not in 1.9.0.dev. The problem seems to be fnCallback(result), as this is the last function which is executed. If I debug and jump over this function I don't reach the next line in the success handler but I get into jquery.js (v 1.6.2 - that's the problem?) into

[code]
// resolve with given context and args
resolveWith: function( context, args ) {
...
finally {
fired = [ context, args ];
firing = 0;
}
}
[/code]

So, the table is shown with data, but of course my custom stuff is missing as well as the click events. Also, fnInitComplete is not fired ...

Do you have any clue? My only assumption (besides a bug :-P) could be the jquery version. Don't know whether you rely on 1.7.x?

Thanks a lot!

John

allan

jQuery 1.3+ should work, so 1.6 will be fine. I've just tried the following code with jQuery 1.6.2:

[code]
$(document).ready(function() {
$('#example').dataTable( {
"bProcessing": true,
"bServerSide": true,
"sAjaxSource": "scripts/server_processing.php",
"fnServerData": function( sUrl, aoData, fnCallback ) {
$.ajax( {
"url": sUrl,
"data": aoData,
"success": function (json) {
console.log( 'before' );
fnCallback(json);
console.log( 'after' );
},
"dataType": "json",
"cache": false
} );
},
"fnInitComplete": function () {
console.log( 'complete' );
}
} );
} );
[/code]

and it seems to work as I would expect. On the console I get:

[quote]
before
complete
after
[/quote]

Are you using the very latest 1.9 development software? If it is still not working with that, is there any chance I can have a link?

Thanks,
Allan

John Archer

Yay, the latest/current version works! The one which not worked was a version from 8th or 9th December when I tested the new fnStateLoadCallback behaviour.

Happy now and really looking forward to 1.9 now. :-)

Thanks for your help and great work!

allan

The best kind of bug, is a bug that has already been fixed :-). Thanks for letting me know!

Nearly there with 1.9 now - just need to finish of the ARIA work and write a bit of documentation...

Regards,
Allan

John Archer

Indeed. :-)

Uh, didn't know the term ARIA until now. Great thing, good luck with that!