Getting filtered/unfiltered rows when using deferred rendering

Getting filtered/unfiltered rows when using deferred rendering

ThefinaleofseemThefinaleofseem Posts: 11Questions: 0Answers: 0
edited April 2014 in DataTables 1.9
I know this subject has come up in the past, but I'm hoping that I might be able to dig out more insight on this as I haven't been able to find a real solution...

I'm using Datatables 1.9.4. I have a table that can potentially be very large. I used deferred rendering to help speed things up a bit. It's not big enough to justify serverside rendering, but it's big enough that it can bog things down a bit. The table is paginated and will be paged with most data sets. In any case, I find myself needing to retrieve all unfiltered rows of the table. Naturally, this won't work with any sort of standard selector as anything past the first page is not rendered and cannot be selected. I can't really post a link to it as it's not public.

The usual suspects aren't effective, such as table._('tr', {"filter":"applied"}). I've dug through the documentation and the table itself in Firebug, but with no luck on finding anything that could be definitively used short of grabbing the original data, grabbing all of the filters, and filtering it all over again manually, which is hardly ideal. To add to the fun, there's a global table filter along with individual column filters.

Is there any avenue to dig into the Datatable and extract this data? Datatables is definitely aware of rows that haven't been rendered yet. It knows how many rows in total there are when filtering regardless of unrendered rows. Is there any way that this data could be used to extract the filtered or unfiltered rows from the original dataset? Indexes or certain row identifiers within the data would work out just fine. Datatables must contain some kind of data on these unrendered and filtered rows tucked away somewhere.

Replies

  • ThefinaleofseemThefinaleofseem Posts: 11Questions: 0Answers: 0
    edited April 2014
    Got it, or at least I hope I do. It seems that fnSettings().aiDisplay contains indexes for all filtered rows that map to the original data values contained in aoData[index]._aData, which appear to be stable regardless of any sorting or filtering on the table. I can simply iterate over aiDisplay, grab the corresponding value from aoData, and extract whatever information I need regardless of whether the row is rendered or not. This seems like it could be a workaround for unrendered row selection with deferred rendering, at least in some cases.

    Can I get a confirmation on this?
  • allanallan Posts: 61,439Questions: 1Answers: 10,052 Site admin
    You could do that... But I would strongly recommend against it :-). The settings object is considered to be private and it can, will and done change between versions.

    The way to get the filtered data is with the `_` method: http://datatables.net/docs/DataTables/1.9.4/#_ . So `table._( 'tr', { filter: 'applied' } ). That is the 1.9- API way of doing it.

    With 1.10 you can use the new rows() method: `table.rows( { filter: 'applied' } ).data().toArray()` - see http://next.datatables.net/reference/api/rows() ( you need to add the `()` to the URL - I need to update my forum auto linker!).

    Allan
  • ThefinaleofseemThefinaleofseem Posts: 11Questions: 0Answers: 0
    Thanks Allan. Unfortunately, with deferred rendering, the standard method will only return the first page. Subsequent pages are not included in table._( 'tr', { filter: 'applied' } ). Versioning may not be a big issue as we're unlikely to change versions once we've settled on a plugin 'round here.
  • allanallan Posts: 61,439Questions: 1Answers: 10,052 Site admin
    Urgh - sorry, yes. The `_` method applies a jQuery selector to the created nodes...

    In which case, 1.9- doesn't have a public API method for getting that information. So yes, your method is possibly the best way (after upgrading of course :-) ).

    Allan
  • ThefinaleofseemThefinaleofseem Posts: 11Questions: 0Answers: 0
    Great, thanks Allan! An upgrade might happen once 1.10 goes final, or perhaps after 1.1x or so. Until then, this will have to do. I'll make sure to comment that block of code to note that it's a version-specific workaround.
This discussion has been closed.