Identify whether the request is navigation or search?

Identify whether the request is navigation or search?

mammarmammar Posts: 4Questions: 1Answers: 0

Hi,

I am using datatables with server side processing with Django. Below is how my config looks like

$(document).ready(function() {
    var $productsTable = $('#dataTableCourse').DataTable({
        'autoWidth': false,
        'processing': true,
        'serverSide': true,
        'deferLoading': {{products_count}},
        'data': {{products|safe}},
        'ajax': {
            'url': '{{products_url}}',
            'data': function(d) {
                var table = $('#dataTableCourse').DataTable();
                d.page = table.page.info().page + 1;
                d.sortColumn = table.order()[0][0];
                d.sortDirection = table.order()[0][1];
                d.searchText = table.search().trim();
            },
            'dataSrc': 'products'
        },
    });

    $('div.dataTables_filter input').unbind();
    $('div.dataTables_filter input').bind('keyup', function(e) {
        if(e.keyCode == 13) {
            $productsTable.search( this.value ).draw();
        }
    });
});

Things are working fine but i am facing a small issue. After performing a search and displaying the search results when i do forward or backward navigation, table.search() gives the searched text which i don't want. My understanding is that when i do navigation search text should not be involved. I am unable to identify in ajax.data function whether this is a search request or navigation request so that i can conditionally send query parameters in ajax request.

Any help would be appreciated.

Answers

  • allanallan Posts: 63,482Questions: 1Answers: 10,467 Site admin

    when i do navigation search text should not be involved

    Since you have server-side processing enabled, it has to be. DataTables will send a request to the server saying "I need page X when the search filter is Y" (or something to that effect.

    When using server-side processing, the two are effectively intermingled.

    Allan

  • mammarmammar Posts: 4Questions: 1Answers: 0

    Can't we use separate urls for search and navigation? Any option/settings that can help me achieve what i need?

  • kthorngrenkthorngren Posts: 21,311Questions: 26Answers: 4,948

    After performing a search and displaying the search results when i do forward or backward navigation, table.search() gives the searched text which i don't want.

    Sounds like you are asking for a find feature versus filtering the table. Is that you want the user to type in text and just find that area in the table instead of filtering the table?

    Kevin

  • mammarmammar Posts: 4Questions: 1Answers: 0

    Kevin,

    Sorry for not being clear. I am not doing or want search feature. My database results are filtered based on what is typed in search input box. On a second thought i think both are same. Anyway what i need is that on navigation(forward/backward) the ajax request should not send search text from the input box to avoid any filtering on backend. For this there could be two solutions:
    1) Separate URLs for search/filter and navigation requests, OR
    2) Distinguish between search/filter and navigation requests in ajax.data method so that i can send the appropriate query params based on request type.

    Hope this is more clear now.

    Ammar

  • kthorngrenkthorngren Posts: 21,311Questions: 26Answers: 4,948

    Sorry, I'm not understanding the end goal of knowing whether the user is searching or navigating the table. If you are wanting to keep the table filtered on navigation then your query will be the same as searching. Depending on your backend DB you need to set the start (offset), length (limit) and search term whether the request is a search or navigation.

    Are you want the filter to be cleared when the user starts navigating?

    Kevin

  • mammarmammar Posts: 4Questions: 1Answers: 0

    Sorry Kevin, Looks like i myself is confused. I will look into this more and then get back to you.

    Thanks a lot for your responses.

This discussion has been closed.