Error when tablesorter is applied to empty table

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Error when tablesorter is applied to empty table

owen_b_leonard-2

I'm using the tablesorter plugin in a web application that sometimes
outputs empty tables. I'm trying wherever possible to catch these
instances and skip the output of the table altogether when necessary,
but it begs the question:

Is there a way to avoid errors when tablesorter tries to sort an empty
table?

Thanks,

  Owen
Reply | Threaded
Open this post in threaded view
|

Re: Error when tablesorter is applied to empty table


1b)
2) Add CSS styling to make the fake row not render:

tr.fake_row {
    display: none;
}

This seems to work effectively, allowing tablesorter to initialize and run error-free and has no impact on the rendered output.  The efficiency loss and bloat of adding 1 line to each table is negligible.
ddopson
owen_b_leonard-2 wrote
I'm using the tablesorter plugin in a web application that sometimes
outputs empty tables. I'm trying wherever possible to catch these
instances and skip the output of the table altogether when necessary,
but it begs the question:

Is there a way to avoid errors when tablesorter tries to sort an empty
table?

Thanks,

  Owen
I have experience the same issue.  It seems to be related to the fact that several parts of the codebase use rows[0] to determine 1) total number of columns, 2) the parser type to use per column (eg "text" vs "digit").  

I would love to see this "bug" fixed.  In the case of the total number of columns, the table headers are sufficient.  In the case of column parser type, it's not important and "text" for all columns would suffice (all sort orders of a 0-length list are equivalent).  While enabling sortable 0-entry tables doesn't seem exciting, this breaks a really common scenario: data driven tables.  I'm constructing a table from data and sometimes, 0 rows are returned.  Worse still, I have N tables on the same page, so a crash on the first 0-entry table prevents the rest of the (not-0-length) tables from being properly initialized.  This bug is a major nuisance and burned several hours of my life.  I'd be willing to contribute to a patch for fixing it if desired.

In the meantime, I found a workaround:

1) create a fake row in each table with contents like ("fake", 123, 123, 123, "fake").  Note how my fake contents match the "type" of the column to avoid confusing the column type detector.

fake123