Updating page selector and row count information when using ajax

[lindonb]

When applying a filter and using ajax, I use code within pager_ajaxProcessing and in a separate function outside of tablesorter to create the values needed to show the proper row information (e.g., "1-25 / 80 (80)") and the page selector dropdown. Is there an easier way to supply the needed values to tablesorter so that the end values are generated automatically within tablesorter as they are when ajax is not used?

Here's what I currently do: I return the start row and filtered number of rows in the HTML. In pager_ajaxProcessing I extract and manipulate those values to calculate the end row, start row and number of filtered pages and create the text for the pager_output option.

Since the gotoPage selector doesn't automatically update, I use another function outside of tablesorter to rebuild the page selector from scratch to show the proper number of pages based on the filtered results.

I set this up a while back and I know a lot of great changes have been made, so I could have missed the fact that this extra coding is no longer necessary. Thanks for any help.

[Mottie]

Hi @lindonb!

I'm not sure why all of that extra coding is needed, the pager plugin/widget should have been doing those calculations all along. I set up these demos (plugin / widget) using the filter and pager. Filter any column and the filtered rows value and page selector will change.

Also, the pager_ajaxProcessing function should not be called when ajax isn't being used.

[lindonb]

Thanks @Mottie,

I agree with you and all works fine when not iusing Ajax, but in my case I am using Ajax. The information on number of rows and the page selector aren't updating for me correctly when using Ajax unless I add extra coding.

[Mottie]

Wow, sorry, I totally misread your question; sorry I've been very busy lately, and distracted.

The totalRows value should be returned from the pager_ajaxProcessing function as obtained from the server. The plugin can then calculate the correct number of available pages and set the page selector appropriately.

Now if you want to display the correct filter row count, this should also be returned from the server. If you look at the documentation for the pager_ajaxProcessing function (link above), it's not super-obvious, but additional data can be returned and used in the pager_output option. This example is from the pager_ajaxProcessing documentation (also issue #326 has a discussion about this):

So, lets say the data sent by the server looks like this:

{
    "total_rows"    : 100,
    "filtered_rows" : 75,
    "new_headers"   : [ "ID", "Name", "Data", "Value" ],
    "data"          : '<tr><td>a123</td><td>abc</td><td>xyz</td><td>999</td></tr>',
    "subject"       : "cheese",
    "tasty"         : "It's delicious!"
}

This pager_ajaxProcessing function must return an object with "total" property; and optionally return "headers" and "rows" properties. As before, "total" is the only required property; if the headers don't need to be changed, don't return a headers array, and if you append the rows to the table yourself within the pager_ajaxProcessing function, you don't need to return a "rows" property.

pager_ajaxProcessing: function(result, table, xhr){
    if (result && result.hasOwnProperty('data')) {

        // "total" is a required property!
        result.total = result["total_rows"];

        // "headers" is optional. This is not needed if the table headers don't change
        result.headers = result["new_headers"];

        // "rows" is optional. No need to return this if you process and add the rows
        // to the table yourself otherwise, return an array of arrays or jQuery object
        // (shown in this example)
        result.rows = $(result.data);

        return result;
    }
}

Now in the output string, you can also reference the extra ajax data:

pager_output : '{startRow} to {endRow} of {filtered_rows} ({totalRows}) rows about {subject} ({tasty})'

I hope that is what you need.

[lindonb]

Thanks @Mottie, that's very helpful for the pager_output. What about the .gotoPage selector - is there a way for it to adjust to the filtered number of pages automatically when using ajax if the filtered number of rows is returned as you suggest above?

[Mottie]

Hmm, yeah, I guess it would be better to have the .gotoPage selector show only the filter page count. I'll get that fixed.

[Mottie]

Try the update I just pushed to the working branch.... when the ajaxProcessing function returns an object, that object can contain a filteredRows value which will update the same-named internal variable and thus update the pager_output and cssGoto selector appropriately.

[lindonb]

Many many thanks @Mottie - works beautifully and saves me a lot of extra code!

[lindonb]

Spotted one remaining issue - when the filter causes no records to be found, neither the pager_output or .gotoPage drop down is updated when using ajax and returning the filtered rows as the filteredRows value.

[Mottie]

I can't seem to target the code that might be causing this issue. Are you sure that your server is returning data, including a filteredRow value of zero?

[lindonb]

Yes, the data seems to be returned including a filteredRow value of 0. One thing I noticed is that the following code at line 502 of widget-pager.js sets p.filteredRows to be equal to result.total instead of result.filteredRows when result.filteredRows is 0:

p.filteredRows = result.filteredRows || result.total;

The above properly sets p.filteredRows to be equal to result.filteredRows when result.filteredRows is greater than 0.

[Mottie]

Ahh, ok, that makes sense. Try the update to the working branch and see if that fixes it.

[lindonb]

That fixes it!

I noticed that the .next and .last pager buttons are not disabled when 0 rows are returned. This is the case whether ajax is used or not so this is actually a separate small bug.

Thanks again for all your help on this!

[Mottie]

Ok, smashed that bug too! :P

[lindonb]

Confirmed smash! Thanks again.