With multiple tables, "Search all tables" works for all tables, but "Search..." only for first one

ma_roberge

I have managed to sort out how to use the multiple tables feature together with the code shown at "Individual column searching (text inputs)" (actually as posted a few years ago). The way in which the tables are identified (with [id^=…]) comes from a solution offered by "bindrid" posted as part of this topic.

My problem is:
* Searching text in any one table, or all of them, when using the "Search all tables" field works OK.
* Searching text using the "Search" box that appears at the bottom of each column works only for the first table.

Please see my code at live.datatables.net/kuviloqe/1/edit

Thanks in advance for help; my knowledge of JavaScript is absolutely minimal.

kthorngren

The main problem is you need to loop through all the tables to apply the column search event handler, for example:

 $("table[id^='table']").each( function () {
   var table = $(this).DataTable();
    table.columns().every( function () {
        var that = this;
        $( 'input', this.footer() ).on( 'keyup change', function () {
            that
                .search( this.value )
                .draw();
        } );
    } );
  });

The second issue is with the loop building the inputs. This statement:

var title = $("table[id^='table'] tfoot th").eq( $(this).index() ).text();

Always chooses the first table so the second doesn't set the placeholder correctly. Simply use var title = $( this ).text(); instead. Here is the updated example:
http://live.datatables.net/kuviloqe/3/edit

Kevin

ma_roberge

Dear kthorngren,

Thank you very much for solving my problem so elegantly. I have simplified things by replacing the instances of "table[id^='table']" with 'table'. It does not matter if each table has an id or not.

kthorngren

It does not matter if each table has an id or not.

Thats correct. You can use a class as shown in this example. This way if you have other tables that aren't Datatables they won't be initialized.

Kevin

ma_roberge

I have just noted a major problem: the natural sort plugin I use in all my tables no longer works with the new code. In the new test case I have added to the HTML the link to the natural.js code and changed the numbers in column "Age" in both tables to read 10, 105, 11. Now, the reverse sort gives 11, 105, 10, and reverting to ascending order does not give 10, 11, 105. What is happening? It used to work perfectly.

kthorngren

You have a type loading the script: <script scr="h..... It should be src=. Here is the updated working script:
http://live.datatables.net/xusamuli/1/edit

EDIT: Thanks for providing simple and useful test cases!

Kevin

ma_roberge

Kevin,

The "scr" was simply a typo when I added the reference to the script; I should have been more careful and look for the obvious. On the other hand, I have been forced to conclude that using 'table' (which my test case did not reflect) rather than "table[id^='table']" **(and give each of my table an individual **id) was essential for natural.js to work.

All is well that ends well. Thanks again.

kthorngren

I have been forced to conclude that using 'table' (which my test case did not reflect) rather than "table[id^='table']" **(and give each of my table an individual **id) was essential for natural.js to work.

Not sure I understand what you mean. The plugin does not know anything about the jquery selector you use. I updated your example to use table and it still works:
http://live.datatables.net/xusamuli/3/edit

Kevin

ma_roberge

This is curious. As much as I can see that your code works, in the instance where you have $("table").DataTable( {, I need to use $("table[id^='table']").DataTable( {, otherwise natural sort breaks. Using either solution works on your side, but not on mine!

kthorngren

Sounds strange. Have you looked for errors in your browser's console? You could do some debugging of this portion of code to see if its working on the columns you expect:

jQuery.extend( jQuery.fn.dataTableExt.oSort, {
    "natural-asc": function ( a, b ) {
        return naturalSort(a,b,true);
    },
 
    "natural-desc": function ( a, b ) {
        return naturalSort(a,b,true) * -1;
    },

Kevin

ma_roberge

I checked and could not find any error, nor were any reported. Natural sort works on all columns, given my use of targets: '_all'.

colin

We're happy to take a look, but as per the forum rules, please link to a test case - a test case that replicates the issue will ensure you'll get a quick and accurate response. Information on how to create a test case (if you aren't able to link to the page you are working on) is available here.

Cheers,

Colin

ma_roberge

Colin,

Thanks for offering to take a look. I am therefore attaching my test case, which took a few days to fine tune. It appears preferable to keep things in one place, even though my post appears to mix two issues: the way in which the tables are referenced and the functioning of the natural plugin with either of these references calls.

Following the lead of Kevin, I used $("table").DataTable rather than $("table[id^='table']").DataTable, the latter of which I am using to reference multiple tables. Doing so has consequences on the natural plugin. My test case thus comments out lines showing a series of possibilities, with explanations.

Depending on which possibility is used, natural sort will work (or not), but a cell with html code will sort at the start or end of the column rather than where expected (or correctly). I also noted a difference in behaviour between using targets: '_all' and targets: 'all' (the latter without the underscore).

I hope that all will be clear and that my test case is flexible enough to show all cases. My aim is to be able to have natural sort do its job correctly, including when some cells have html tags. So far, I have used a symbol like a bullet at the end of such entries to ensure correct sorting when I would prefer using bold or italic.

Test case: live.datatables.net/jogilipa/1/

kthorngren

I also noted a difference in behaviour between using targets: '_all' and targets: 'all' (the latter without the underscore).

The columnDefs.targets docs state the following for options:

0 or a positive integer - column index counting from the left
A negative integer - column index counting from the right
A string - class name will be matched on the TH for the column (without a leading .)
The string "_all" - all columns (i.e. assign a default)

Using all is not an option unless you have that assigned asa a classname.

$("table").DataTable rather than $("table[id^='table']").DataTable, the latter of which I am using to reference multiple tables. Doing so has consequences on the natural plugin.

Please provide the specific steps to show that using one or the other changes the behavior of the natural sorting plugin. In your test case the sorting results appear to be the same no matter which selector I use.

but a cell with html code will sort at the start or end of the column rather than where expected (or correctly)

    $("table").DataTable( {
          "columnDefs": [
//With '_all', natural sort does not work, and html is moved at start/end.
            { type: 'natural-nohtml', targets: '_all'},
         ]
    });

See this example:
http://live.datatables.net/rodozako/1/edit

With this option the sorting seems to work correctly for columns with HTML and columns that don't have HTML. This code, in the plugin, is used to remove the HTML if you use the natural-nohtml option. This appears to work for all the columns in your test case:

        // remove html from strings if desired
        if (!html) {
            x = x.replace(htmre, '');
            y = y.replace(htmre, '');
        }

As an optimization suggestion you may want to specify which columns use natural-nohtml as that adds two extra regex operations for each cell. Might have a performance impact depending on the amount of data you have.

I'm not able to reproduce any issues with the natural plugin. Please provide specific steps to show the problems you are having. Maybe have a specific test case for each issue so we don't need to rely on commenting out code.

Kevin

ma_roberge

Kevin,

I have finally discovered the source of the problem when alternating between the call to natural.js in your code and mine. The culprit was that only the groups natural-asc and natural-desc were present in the final block of code in the local version of the plugin I am using. In other words, the two natural-nohtml entries were missing. I suspect that I may have uncarefully deleted them when installing the plugin in 2015 because I thought they would not be of use to me at the time.

I do not foresee any problem in using '_all' because my tables usually have 20 to 30 rows, and only in a few cases up to 100 or so. This is not likely to impact performance.

My problem is thus solved, and I thank you very much for all the help.

kthorngren

Glad you found the issue

Kevin