Default export options?

Default export options?

JammySlayerJammySlayer Posts: 43Questions: 12Answers: 2

CSV export has started including subheading since moving from 1.10.15 to 2.0.5

I was hoping something like:
$.extend($.fn.dataTable.ext.buttons.csvHtml5, {
exportOptions: {
customizeData: function(data) {
data.headerStructure.pop();
}
}
});

Would have worked, but doesn't appear to, is there an expected way of adding universal settings for buttons?

This question has an accepted answers - jump to answer

Answers

  • JammySlayerJammySlayer Posts: 43Questions: 12Answers: 2

    Should clarify my subheader contains the filters and the csv is listing the content of a bootstrap drop down, which is a hidden ul...

  • kthorngrenkthorngren Posts: 21,289Questions: 26Answers: 4,943
    edited April 25 Answer ✓

    Your code snippet removes the second header (actually last header). See this test case:
    https://live.datatables.net/patameye/1/edit

    subheader contains the filters and the csv is listing the content of a bootstrap drop down, which is a hidden ul.

    I'm not sure what you mean by subheader and how you are doing this: "bootstrap drop down, which is a hidden ul.". Please update the test case to show this issue. It includes BS 5..

    Kevin

  • kthorngrenkthorngren Posts: 21,289Questions: 26Answers: 4,943

    Just a thought, make sure you place $.extend($.fn.dataTable.ext.buttons.csvHtml5, { before Datatables is initialized.

    Kevin

  • JammySlayerJammySlayer Posts: 43Questions: 12Answers: 2

    Ah worked it out, I was doing exportOptions on the instance of the button I was using which was overwriting it. be nice if the individual instance would extend the existing settings.

    Regarding dropdowns I just talking about the normal bootstrap drop downs:
    https://getbootstrap.com/docs/5.3/components/dropdowns/
    Which use a toggle on a hidden UL, and the csv was showing the content of the UL.

    Here's how I was falling over (but in my case there was a lot more code/files involved so harder to notice :D)
    https://live.datatables.net/patameye/3/

    I guess I can make these particular ones also be generic, but if I ever need any other options I'll have to remember to add the options again for that page.

    (Using datatables on a number pages and want things to be consistent so trying to make the defaults automatically be applied)

  • kthorngrenkthorngren Posts: 21,289Questions: 26Answers: 4,943

    I see. I'm not sure what the buttons code does internally but it looks like it doesn't merge the $.fn.dataTable.ext.buttons.csvHtml5 setting with the exportOptions defined on the specific button. However it looks like you can do that. For example:
    https://live.datatables.net/bajodowo/1/edit

    @allan might have a better suggestion.

    Kevin

  • JammySlayerJammySlayer Posts: 43Questions: 12Answers: 2

    I guess I could make a method to simplify that approach:
    https://live.datatables.net/bajodowo/2/

    But would be nice to know if there's not a more correct way of managing it

  • JammySlayerJammySlayer Posts: 43Questions: 12Answers: 2

    That's annoying hadn't realised that columns: ":not(.export-never)" has also been broken, has to be on every row now rather than just the header row?

  • allanallan Posts: 63,434Questions: 1Answers: 10,458 Site admin

    I don't think it has been broken, it is more that the export now supports multi-row headers and footers, and that needs to be accounted for. If you don't want the second row in the header to be part of the export, have a look at this example which shows how to avoid that.

    Allan

  • JammySlayerJammySlayer Posts: 43Questions: 12Answers: 2

    The export-never thing I used to stick on the column header only see:
    https://live.datatables.net/bajodowo/2/

    Which used to work, as opposed to kthorngrens example:
    https://live.datatables.net/bajodowo/1/edit

    Where it's dependant on using colDefs to get the export-never class added to every cell in the column. I can work with it, as I build my col defs with a function that uses the header row, but it was nicer when all cell in a column could work off the header for things like this

  • kthorngrenkthorngren Posts: 21,289Questions: 26Answers: 4,943

    If you add the classname to both header rows it works:
    https://live.datatables.net/bajodowo/3/edit

    It probably has something to do with how the new buttons supports multiple header rows. Previously, I believe, the exported header followed the orderCellsTop setting which is probably where you had the class assigned.

    Kevin

  • allanallan Posts: 63,434Questions: 1Answers: 10,458 Site admin

    That is correct - the selector will run on all of the rows, so if you are (de)selecting by class, you'd need that on all cells that should be removed.

    I've got orderCellsTop marked as deprecated at the moment - I'm reviewing that decision! It is useful at times :)

    Allan

  • JammySlayerJammySlayer Posts: 43Questions: 12Answers: 2

    Ah yeah, we use orderCellTop as we use a subsequent header for filters

    Could do a class against the tr within thead that it abides by for export and ordering?

    I say the above as I'm now having issues with a table that has a table grouping too... never a one size fits all unfortunately

  • kthorngrenkthorngren Posts: 21,289Questions: 26Answers: 4,943

    Could do a class against the tr within thead that it abides by for export and ordering?

    See this example for controlling where the order listeners are placed.

    I say the above as I'm now having issues with a table that has a table grouping too

    What problems? Can you provide a test case show the issues?

    never a one size fits all unfortunately

    Nope, thats what makes it fun :wink:

    Kevin

  • JammySlayerJammySlayer Posts: 43Questions: 12Answers: 2
    edited April 29

    It's an issue of making the header of the csv using the data.headerStructure.pop(), so I've gone for the making a utility that contains the defaults, and then able to overwrite them using the following:

    exportOptions: dtUtils.csvExportOptions({customizeData: function(data) {
    data.headerStructure.shift();
    }})

    Basically we want the sub header to be the header for it rather than the top header... it's a bit of a oddity on our normal usage.

    Can't really give better examples as our implementation uses a fair amount of deviation from the standard help stuff, such as we build our columns with:
    columns: dtUtils.buildDataArrayFromTableHeaders(tableId)

    Which hoovers up all the columns in the theader to get their id's which is then used to get the data attribute, alone with using data-* for datatypes and such. Issue being I did most of this stuff years ago so now struggling to remember how anything works :blush:

  • JammySlayerJammySlayer Posts: 43Questions: 12Answers: 2

    Anyway thanks for the help with this, will call the ticket done, numerous fixes in numerous places later and I think everything is working as before, think the main thing to come out of it is that it'd be nice if declaring export options would work with defaults (and possibly other config setters), rather than just overwriting them, but I guess it comes down to how frequently this is an issue to others

  • allanallan Posts: 63,434Questions: 1Answers: 10,458 Site admin

    Hi,

    Great to hear you got there in the end.

    the main thing to come out of it is that it'd be nice if declaring export options would work with defaults (and possibly other config setters), rather than just overwriting them

    I'm trying to understand this point. It is possible to set a default for the exportOptions, but yes, if you were then to set a value for it, that will overwrite the default.

    I might have misunderstood the intention though?

    Allan

  • JammySlayerJammySlayer Posts: 43Questions: 12Answers: 2

    Hey @allan yeah, I'm saying if I set some defaults for exportOptions I believe it disregards all of them when I do anything with exportOptions...

    see:
    https://live.datatables.net/patameye/3/edit

    It's lost the header pop done via $.extend($.fn.dataTable.ext.buttons.csvHtml5 in favour of the unrelated changes done in export options, as it's a full over write, no depth. Meaning exportOptions.customizeData is lost when setting exportOptions.column

  • JammySlayerJammySlayer Posts: 43Questions: 12Answers: 2

    I guess what I'm ultimately getting to is it'd be nice if we could have a dataTables.defaults.exportOptions.* and potentially all other options that could have defaults which when you then make the table it combines (with depth). Still want the initiator to win, but only for deep overwrites

  • allanallan Posts: 63,434Questions: 1Answers: 10,458 Site admin

    Ah I see! Merging the objects together. Yes, I agree - that should be done. I've got that logged now and it will be done :)

    Allan

Sign In or Register to comment.