Pager: fixed height problems.

[glend1]

I have noticed two issues,

The first is related to child rows, when hiding and showing child rows the height changes, I don't know of a good solution for this the only thing I can think of is hiding the bottom visible row, this causes problems if there are multi-child rows or if the user expands the bottom row. It could also remove a child-row's visibility if the bottom rows child is expanded when the user expands a row above.

The last issue is that when filtering results/rows the fixed height option on the pager is completely ignored. I assume this is because the fixed table height is set when the pager is called and is not read when filtering.

I have removed the fixed height option from my code and will include it again when it behaves more consistently.

[Mottie]

Hi @doveyg!

Yes, I wasn't sure how to handle child rows within the pager. Do you think it's a good idea to have a solitary child row visible at the top of a page? Wouldn't that be bad UI? I am completely open to discussion on this topic.

As for filtering and maintaining a fixed height, that does appear to be an issue. I'll add it to my to-do list.

[glend1]

No, I don't think that's good design. It would create distance between what was selected and what is shown, perhaps another idea would be to open a floating style tooltip in place of the next row/footer. Without actually seeing what it would look like I don't know for sure if it would be better a different way.

[Mottie]

The only solution I can think of right now would be to copy the parent & child rows into a separate area. Something like this demo:

$(function () {

    var $table = $('.tablesorter');

    $table.tablesorter({
        theme: 'blue',
        // this is the default setting
        cssChildRow: "tablesorter-childRow",

        // initialize zebra and filter widgets
        widgets: ["zebra", "filter", "pager"],

        widgetOptions: {
            // include child row content while filtering, if true
            filter_childRows: true,
            // class name applied to filter row and each input
            filter_cssFilter: 'tablesorter-filter',
            // search from beginning
            filter_startsWith: false,
            // Set this option to false to make the searches case sensitive 
            filter_ignoreCase: true
        }

    })
    .tablesorterPager({
        container: $('.pager'),
        output: '{startRow} - {endRow} / {filteredRows} ({totalRows})',
        removeRows: false,
    });

    // hide child rows
    $('.tablesorter-childRow td').hide();

    // Toggle child row content (td), not hiding the row since we are using rowspan
    // Using delegate because the pager plugin rebuilds the table after each page change
    // "delegate" works in jQuery 1.4.2+; use "live" back to v1.3; for older jQuery - SOL
    $table.delegate('.toggle', 'click', function () {

        var $clone = $table.clone(),
            $cTbody = $clone.find('tbody').empty(),
            $target = $(this).closest('tr');

        // table copy should not appear sortable
        $clone.find('thead').children().children()
            .addClass('sorter-false');

        // copy parent & child rows into copy
        $target
            .add( $target.nextUntil('tr.tablesorter-hasChildRow') )
            .clone()
            .appendTo( $cTbody )
            .find('td').show();

        $('.showChild').empty().append( $clone );

        return false;
    });

});

But I don't think this should be a choice I force on to the developers.

[glend1]

I agree, but I feel a default should be provided for child-row manipulation and another option to show/hide child rows on load, the options should be provided whereby you are able to replace the default behavior with user defined functions.

[Mottie]

This patch 3c0380c fixes the fixedHeight issue.

I'll work on the child-row part of this issue soon.

[glend1]

I feel like I'm making you do too much work, I think I have discovered another issue.

1. Turning pages and filtering records scrolls the page when the table is at the bottom of the html, this conflicts with the fixed height issue because the "whole table" isn't visible and I loose my pager off the bottom of the HTML. Effectively nullifying this patch.
2. When the Tablesorter tables row count is less than the pager size setting blank rows are created needlessly, what do you think I should do about this?
3. Is there a calculated size option for pagers output?

[Mottie]

1. I'm not sure what you mean in your first point above.

2. In order to maintain the fixed height, a blank row (<tr> only) is added with a calculated height; is this causing a problem for you?

3. Again, I'm not sure what you mean... the calculated height of the tbody is saved in:

     $('table').data('pagerSavedHeight');

   This height is recalculated whenever the pager is enabled, the table gets updated ("updateComplete" event gets triggered), or the pager size selector is changed.

   There is no option to set this height, it is calculated from a row height times the pager size.

[glend1]

1. Imagine I have a Tablesorter table at the bottom of my webpage, changing the page using the pager or applying a filter to one of the columns changes the visible rows and applies a fixedHeight. The problem that I am experiencing is that the page always seems to scroll to the bottom of the last visible row rather than the bottom of the table. If its just my code then any idea what would cause that?
2. Only if the table row count is smaller than the pager size value. Sometimes my SQL query that generates the table returns fewer results than what is set by the pager size. I would like the option to choose if the table pager height is applied or if it is ignored when the table is row count total is less than the pager size. perhaps a "maxHeight" option for the pager in addition to "absoluteHeight".
3. I wish to display the pager size value in my pager though the "output" option. Is that possible

[Mottie]

1. The only widget that scrolls the page to the top is the stickyHeader widget

     stickyHeaders_filteredToTop: true, // scroll table top into view after filtering

2. The pager does add a row to measure its height, but then it immediately removes it. The row that is added and kept in the table is only done when the height of the pager doesn't match the saved tbody height. So There is no extra row if the height matches.

3. I guess it isn't documented, but add a {page} to the output option string to show the set pager size.

[Mottie]

This fix is now available in v2.18.0.