Prevent cache from preserve on browser
Prevent cache from preserve on browser
I am using a table with html objects, when I click on a check box of a row and press the execute button, I go to the server (server side processing) and reload again all the content of the table to show the updates.
The problem is the changes are not displayed, the content is kept on the browser, in the cache.
I wonder if there is a parameter to use with dataTables or JQuery similiar to:
preventCache: true
used with dojo.xhrGet()
that exactly does what I need in but in dojo framework.
I hope someone can help me.
Thanks in advance.
The problem is the changes are not displayed, the content is kept on the browser, in the cache.
I wonder if there is a parameter to use with dataTables or JQuery similiar to:
preventCache: true
used with dojo.xhrGet()
that exactly does what I need in but in dojo framework.
I hope someone can help me.
Thanks in advance.
This discussion has been closed.
Replies
There are a couple of options you have here to over come this:
1. Use POST - http://datatables.net/1.5-beta/examples/server_side/post.html which won't be cached
2. Use a custom server 'get' function - similar to that shown here: http://datatables.net/1.5-beta/examples/server_side/custom_vars.html . You can replace the standard Ajax call that DataTables uses with whatever XHR (or data get in general - it could be used with AIR's DB or Gears for example) you want
3. You could insert a random variable - which would probably stop it caching.
Regards,
Allan
1) What caused the IE cache issue?
2) What caused the edited field result to display in the wrong column?
History:
I just encountered this issue. Everything was working fine with Firefox and IE6/7. As of Friday (when I noticed the issue), edited values (via jEditable) were not being diplayed in IE7 unless the temporary files were deleted and the page was refreshed. Firefox continued to work as intended. Note that the updated value was displayed briefly (in the incorrect column) before being overwritten with the original value. It does appear that the results were cached. Even refreshing the table would not update the value. Needless to type, I'm happy datatables is online again --- Using POST instead of GET resolved the issue (after a lot of time spent unsuccessfully debugging).
That said, I'd like to know what caused this issue to begin with. If it's associated with an IE7 update, so be it... however, after the issue began, IE6 (via the nice program Multiple IEs) exhibited the same behavior. Regarding the incorrect field briefly displaying the data --- Could this have something to do with the column ID being off? I'm hiding a column and another column is hidden and used as a row detail. The correct column ID is being passed to the server side processing page... but is it possible that the return is going to the wrong column (which is what appears to be happening)? I can't shake the feeling that it has something to do with the row detail column throwing things off. If that makes sense, does anyone have an idea?
Follow-up:
If there's a way for me to check (via FireBug or another tool), please advise. Everything seems to be working now, but I'm concerned this is a workaround and not a true fix. I'd be happy to be wrong.
Thanks so much,
Rob
In answer to question 1, IE's behaviour with XHR which duplicate GET data is to use cached values. So if I were to send get.php?allan=1 to my server, and then alter the server code, so it would respond differently next time, IE would not notice this (unless I set the HTTP expire headers). So this is what was happening in valdezr's case, and presumably your own as well.
Now the way around that is to make the data in the GET different on each request. This wasn't always true in DataTables 1.5 betas up to, and including, 9. DataTables 1.5 beta 10 how adds another variable to the request which is always different for every draw (required to overcome a timing issue - and solving this problem as well is a side-benefit).
The other way around the issue is to use POST - which IE will not cache. It's a work around certainly, but a perfectly valid one. 1.5 b10 will hopefully be out fairly soon, so you can use that if you want when it is out, but I don't see anything wrong with using POST.
Regarding your second question - that's a bit more difficult to answer. If the data displayed is out of sequence, then that would suggest that the server is sending back data in an unexpected order. You can get around this using sColumns, but it's probably easiest just to check that the server is returning the data in the expected order using Firebug or something like that.
Hope this puts your mind a ease a bit!
Regards,
Allan
Using POST is working, I just don't understand what happened to cause GET to stop working. The only explanation I have is that a recent IE7 update caused the cache issue.
I don't understand why the data being displayed out of sequence. It's odd. After submitting an edit via jEditable, the correct value flashes briefly in the wrong field, then the table is updated appropriately. I've since removed the return value from the response, so it is just a flash now, which I can live with for the time being. It may be a coincidence, but this behavior began after I hid two columns and used one of the hidden columns as a row detail. If you've any debugging suggestions, I'd be happy to follow-up on this issue when I have time. Otherwise, I'll get to it and if I find anything, I'll let you know. It may be helpful to someone.
Take care,
Rob
I'm not sure why upgrading to IE7 would effect this. If anything I would have thought IE7 would be less aggressive with it's cache. But perhaps it changed some setting which triggered this... Either way, this result isn't surprising.
With regard to jEditable - it's odd that it would post the result in the wrong element. Having said that, I think I might know what it is (possibly...). The hidden columns will not effect the result of fnGetPosition(), and as such if you are using that to calculate where the element should be updated, that might well cause what you are seeing. There are a couple of internal functions which you can use to calculate visible from total columns (or the other way around) as needed (in the oApi object).
Allan
You're right... fnGetPosition is being used. Nice call! Unless someone already has a solution, I'll look into this once I have more time and will share my solution.
Thanks, Rob
[code]
"fnRowCallback" : function (nRow, aData, iDisplayIndex) { // row selection callback
$(nRow).attr('id', aData[1]); // set ID for current TR
for (i = 0; i < aData.length; i ++) {
$('td.editable:eq(' + i + ')', nRow)
.editable('INCLUDES/grid_edit.php', {
"callback": function (sValue, y) {
// Redraw the row from the new data on the server
var aPos = oTable.fnGetPosition(this);
oTable.fnUpdate(sValue, aPos[0], aPos[1]);
},
"height": '14px',
"cancel": 'Cancel',
"submit": 'OK',
"indicator": '',
"tooltip": 'Double-click to edit...',
"submitdata": function() { // Additional $_POST parameters
var aPos = oTable.fnGetPosition(this);
return {
"record_id": aData[1],
"column_id": aPos[1]
};
},
"event": "dblclick"
});
}
return nRow;
}
[/code]
There is 'add_never_cache_headers' method which takes response object and adds necessary headers to tell browser not to cache data (docs: http://docs.djangoproject.com/en/1.2/ref/utils/#django.utils.cache.add_never_cache_headers)