SearchPanes feature request: Disable multi-select and force a select

SearchPanes feature request: Disable multi-select and force a select

Loren MaxwellLoren Maxwell Posts: 406Questions: 99Answers: 10

Not sure if this has been entertained, but a feature I'd like to see for SearchPanes is the ability to disable multi-select on specific panes and to also identify a pane as requiring at least one select, which I assume would additionally require a preselect as a default or just ignoring a deselect click if there's only one item selected.

If there's currently a way to accomplish either, I'd welcome a point in the right direction!

This question has accepted answers - jump to:

Answers

  • sandysandy Posts: 913Questions: 0Answers: 236
    Answer ✓

    Hi @Loren Maxwell,

    Firstly, you can disable multi-select by making use of searchPanes.dtOpts and select.style setting it to single.

    Secondly, again making use of searchPanes.dtOpts, you can use select.toggleable and set it to false to do exactly as described above.

    Take a look at this example - it shows both of the above.

    Hope this helps,
    Sandy

  • Loren MaxwellLoren Maxwell Posts: 406Questions: 99Answers: 10

    Wow, that's awesome and easy . . . I was so focused on the searchPanes options that I didn't even think about the dtOpts option.

    Now, suppose I wanted to ensure at least one selection was made across the four tables in the example . . . there's no out of the box solution with the options, right? I'd have to use jQuery and the API to produce that effect?

  • sandysandy Posts: 913Questions: 0Answers: 236

    @Loren Maxwell ,

    Afraid so, SearchPanes doesn't communicate between different tables.

    Thanks,
    Sandy

  • Loren MaxwellLoren Maxwell Posts: 406Questions: 99Answers: 10

    @sandy, any examples of how a click event on a searchPane row can be detected and how each of the searchPanes can then be accessed and their dtOpts values changed?

    I've tried to find something in the documentation and the forums, but haven't seen anything that comes close.

    I realize I can create an event listener on #DataTables_Table_0 and so forth, but I'm hoping there's a solution that would allow scaling regardless of the number of searchPanes in use.

  • sandysandy Posts: 913Questions: 0Answers: 236

    Hi @Loren Maxwell ,

    Take a look at this example. It shows how you can set a listener for all of the SearchPanes on the page and access the selected rows.

    For changing dtOpts on each pane, it will depend a bit on the behaviour that you want. Are you wanting to do a blanket change on all SearchPanes on a select? Or just the one with the select?

    You could just configure the tables in the event listener where I am getting the row data. That is easy enough to do for the current SearchPane, or also to iterate through all of them using the $('.dtsp-searchPane table:visible') selector. But depending on other config options and api calls, your configuration that you add may be altered by searchPanes.dtOpts.

    If that turns out to be the case then you will probably have to note the selections and reinitialise SearchPanes with your new searchPanes.dtOpts and use the previous selections to set columns.searchPanes.preSelect. It will depend on what you are wanting to do.

    Thanks,
    Sandy

  • Loren MaxwellLoren Maxwell Posts: 406Questions: 99Answers: 10

    @sandy, here's my solution based on your very helpful advice:
    http://live.datatables.net/peguwimu/3/edit

    This ensures that there is always at least one selection in one of the searchpanes, regardless of how many there are.

    For my use, I want the user to be able to filter the data in various ways, but never have access to all the data at once. I've additionally set the style to single so the user can't simply select everything in the searchpane to access all the records anyway.

    A couple of notes for anyone who wants to implement it, plus I';d welcome any improvements anyone might have!

    1) Make sure the table is initialized properly by setting toggleable to false, a preSelect for at least one searchpane, and clear to false to disallow a user from clearing all searchPanes selections in that way:

        searchPanes:{
          clear: false,
          dtOpts:{
            select:{
              style: 'single',
              toggleable: false
            }
          }
        },
        columnDefs: [
          {
            searchPanes: {
              preSelect: ['London']
            },
            targets:[2]
          }
        ]    
    

    2) Here's an expanded $(".dtsp-searchPane table:visible") listener that counts the number of applied selections for all searchpanes on select and deselect and if it is one then it disables toggleable on all searchPanes or enables it if there is at least one selection already applied:

      $(".dtsp-searchPane table:visible").DataTable().on("select deselect", function(){
        var appliedfilters = 0;
        $(".dtsp-searchPane table:visible").each(function() {
          appliedfilters += $(this).DataTable().rows({selected:true}).data().toArray().length;
        });
        $(".dtsp-searchPane table:visible").each(function() {
          if (appliedfilters == 1) {
            $(this).DataTable().select.toggleable(false)
          } else {
            $(this).DataTable().select.toggleable(true)
          }
        });
    
  • Loren MaxwellLoren Maxwell Posts: 406Questions: 99Answers: 10

    Another quick example of what's possible if anyone's interested.

    Here I want the user to be able to select only one option between all the seachpanes:
    http://live.datatables.net/peguwimu/4/edit

    Below is the specific code for $(".dtsp-searchPane table:visible") portion (note the difference of using only the select event rather than both select deselect as above to avoid infinite recursion):

      $(".dtsp-searchPane table:visible").DataTable().on("select", function(){
        var selectedpane = $(this).attr("id");
        $(".dtsp-searchPane table:visible").each(function() {
          if ($(this).attr("id") != selectedpane) {
            $(this).DataTable().rows().deselect();
          }
        });
      });
    

    Again, I'd welcome any improvements!

  • Loren MaxwellLoren Maxwell Posts: 406Questions: 99Answers: 10

    @sandy, ok I tried to implement my second iteration of the searchpane interactions from the post immediately above.

    Specifically I want the user to be able to select only one option between all the seachpanes, which I had successfully done here:
    http://live.datatables.net/peguwimu/4/edit

    However, in implementing, the results are inconsistent as to whether the $(".dtsp-searchPane table:visible") actually detects a select on the searchPane.

    Here's the first case, which works correctly:
    https://ghsfha.org/w/Special:SchoolHome?view=development&school=Lovejoy

    To see the intended functionality:
    1) Select "2015" in the season searchPane; the console will note "a searchPane option was selected"
    2) Select "Bradwell Institute" from the opposing program searchPane; "2015" from the season searchPane will be deselected and the console will note "a searchPane option was selected"
    3) Select "Bill Young" from the opposing coach searchPane, etc.

    Perfect!

    However . . .

    This page doesn't work:
    https://ghsfha.org/w/Special:SchoolHome?view=development&school=Lowndes

    To see the issue:
    1) Select "2015" in the season searchPane; although the selection changes, no note appears in the console which seems the listener did not recognize the select
    2) Select "Americus" from the opposing program searchPane; "2015" from the season searchPane is not deselected and the console does not note "a searchPane option was selected"
    3) Select "Al Hughes" from the opposing coach searchPane, etc.

    Aside from the data, there should be no difference between the pages, so I can't figure out why one would work and the other would not.

    Also, it is consistent between the parameters . . . In other words, the Lovejoy page always works and the Lowndes page never works. Same for other teams that I've tried, they either always work or never work.

    Any thoughts?

  • Loren MaxwellLoren Maxwell Posts: 406Questions: 99Answers: 10
    edited June 2020

    Ok, I've found the pattern of when a listener will work properly and when it won't.

    For teams that have 500 or fewer records (Lovejoy has 343 games) the listener works properly. For over 500 records (Lowndes has 629 games) the listener does not work correctly.

    I've tested the SQL to return 500 and 501 records for various teams and everytime a the data has over 500 records the listener does not work properly.

    This is true for both Chrome and Firefox.

    Is there something in the DataTables select extension that acts oddly when there are more than 500 records? Or in searchPane's use of it on the searchPane itself?

  • Loren MaxwellLoren Maxwell Posts: 406Questions: 99Answers: 10

    Ok, @sandy, here's a working example building on the previous examples:
    http://live.datatables.net/peguwimu/6/edit

    This includes a 501 record dataset, so it doesn't work as desired (i.e., it allows multiple searchPanes to have a selection when it should allow only one at a time).

    However, delete the very last record and everything works as it should.

  • sandysandy Posts: 913Questions: 0Answers: 236
    Answer ✓

    Hi @Loren Maxwell ,

    This had me stumped for a while! I then remembered that we had added a check a long time ago to try and avoid SearchPanes running before the table was loaded. This was later improved with this, although now the two are merged together.

    The 100 ms wait is now unnecessary, as we know that the table is initialised. I've removed it so this will be available in the next SearchPanes release which we hope will be in the next few weeks. Until then you can access the fix from the nightly builds.

    I've updated your most recent live example to use the nightly code and it is now working.

    Thanks,
    Sandy

  • Loren MaxwellLoren Maxwell Posts: 406Questions: 99Answers: 10

    Thanks, @sandy!

This discussion has been closed.