Default export options?
Default export options?
JammySlayer
Posts: 39Questions: 11Answers: 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
Should clarify my subheader contains the filters and the csv is listing the content of a bootstrap drop down, which is a hidden ul...
Your code snippet removes the second header (actually last header). See this test case:
https://live.datatables.net/patameye/1/edit
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
Just a thought, make sure you place
$.extend($.fn.dataTable.ext.buttons.csvHtml5, {before Datatables is initialized.Kevin
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)
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.csvHtml5setting with theexportOptionsdefined 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
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
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?
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
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
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
orderCellsTopsetting which is probably where you had the class assigned.Kevin
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
orderCellsTopmarked as deprecated at the moment - I'm reviewing that decision! It is useful at timesAllan
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
See this example for controlling where the order listeners are placed.
What problems? Can you provide a test case show the issues?
Nope, thats what makes it fun
Kevin
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
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
Hi,
Great to hear you got there in the end.
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
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
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
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