pagination defect in 1.8.1
pagination defect in 1.8.1
pgalgano
Posts: 6Questions: 0Answers: 0
This defect appears in the 1.8.2dev version actually that fixed the overflow display error, but dont think any code change was specific to that problem so listing it in 1.8 thread.
Use case is I have a ajax call I do myself to get a large set of JSON data back from the server, over 12K objects for full set. Initial calls works and renders fine. I then go to the last page of the results which is still fine.
I then do a new search that will bring back a smaller number of results. The paging and rendering is stuck at what would be the index of the last page of the previous search and the paging control shows something like showing 11706 to 9 of 9 entries. The paging buttons are fine and as soon as I click on any of these the paging number corrects itself. It is as if there is an index variable within the table that is not getting cleared out between renderings.
The following is the logic I use to render the table.
[code]
//pre ajax call to get json data
function preRequest(){
datatable.fnProcessingIndicator(true); // this is an exposed wrapper around the oApi._fnProcessingDisplay call to turn the processing on
datatable.fnClearTable(); //remove the previous search results, after this call paging will change to 0 to 0 of 0 results
}
//post json values returned
function processData(data){
datatable.fnAddData(data); //adds new object array to the table and renders results. Everything is fine except the init index in the paging //control and the table is blank until one of the paging control buttons is clicked.
datatable.fnProcessingIndicator(false);
}
[/code]
other item of possible interest is that I have bDeferredRendering turned on.
Use case is I have a ajax call I do myself to get a large set of JSON data back from the server, over 12K objects for full set. Initial calls works and renders fine. I then go to the last page of the results which is still fine.
I then do a new search that will bring back a smaller number of results. The paging and rendering is stuck at what would be the index of the last page of the previous search and the paging control shows something like showing 11706 to 9 of 9 entries. The paging buttons are fine and as soon as I click on any of these the paging number corrects itself. It is as if there is an index variable within the table that is not getting cleared out between renderings.
The following is the logic I use to render the table.
[code]
//pre ajax call to get json data
function preRequest(){
datatable.fnProcessingIndicator(true); // this is an exposed wrapper around the oApi._fnProcessingDisplay call to turn the processing on
datatable.fnClearTable(); //remove the previous search results, after this call paging will change to 0 to 0 of 0 results
}
//post json values returned
function processData(data){
datatable.fnAddData(data); //adds new object array to the table and renders results. Everything is fine except the init index in the paging //control and the table is blank until one of the paging control buttons is clicked.
datatable.fnProcessingIndicator(false);
}
[/code]
other item of possible interest is that I have bDeferredRendering turned on.
This discussion has been closed.
Replies
Allan
No javascript errors are being thrown. The display issue discussed is occuring at line 5132 of the 1.8.2.dev nightly build from before july3rd in function _fnUpdateInfo ( oSettings ).
the line
iStart = oSettings._iDisplayStart+1, iEnd = oSettings.fnDisplayEnd()
When I do my large search of 5000+ results and go to the last page _iDisplayStart is set to 5000 somewhere, not sure the location of that part. When I call fnClearTable() the _fnUpdateInfo is called and the right paginfg info is displayed but the reason for this is explained next paragraph. Then when I call the fnAddData function passing in a result of 2 values. When this eventually calls the _fnUpdateInfo function the value of _iDisplayStart is set to 5000 even though there are only 2 results in the current dataset. Not sure where the old value of 5000 is getting resurrected from at this time. The iEnd is properly set to the value of 2. In stepping through the function fnDisplayEnd the value of _iDisplayEnd is set to 2.
The initial clear is showing the right info because of the check that uses a hardcoded string when the recordsToDisplay = 0 check in the _fnUpdateInfo call. Even when the fnClearTable() is called the value of _iDisplayStart is coming back as the 5000 value each time through the function.
Adding
oSettings._iDisplayStart=0;
to the end of the _fnClearTable function resolves the issue for me but I am not sure if this would introduce a different defect.