Default export options?

JammySlayer

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?

JammySlayer

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

kthorngren

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

kthorngren

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

Kevin

JammySlayer

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 )
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)

kthorngren

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

JammySlayer

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

JammySlayer

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?

allan

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

JammySlayer

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

kthorngren

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

allan

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

JammySlayer

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

kthorngren

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

Kevin

JammySlayer

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

JammySlayer

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

allan

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

JammySlayer

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

JammySlayer

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

allan

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