Export making use of data-* attribute

ffe

In our Datatables we sometimes show icons instead of text value, for example a check/cross symbol indicating "yes"/"no". Of course, these symbols are not going to be exported, but I am looking for an easy way to export the text instead.

To be more precise, I would like to add the export text as a data attribute to the table cell:
<td data-order="yes" data-export="yes"><i class="fa fa-check"></i></d>

I tried to use both the documented data-order and the "undocumented" data-export attribute (which has been used in some examples) with exportOptions: { orthogonal: 'order' } and exportOptions: { orthogonal: 'export' } respectively, but the column remains empty in my Excel file.

My question is similar to this one, however it is not clear to me if I have to use the format function to achive this or do I have an error in my code and it should be working to use the data-* attribute?

I also wonder if it would be a good built-in functionality to have an official orthogonal data-export attribute?

colin

We're happy to take a look, but as per the forum rules, please link to a test case - a test case that replicates the issue will ensure you'll get a quick and accurate response. Information on how to create a test case (if you aren't able to link to the page you are working on) is available here.

Cheers,

Colin

ffe

Hi Colin,

I created a test case: http://live.datatables.net/kuqawedu/2/edit?html,js,output

I added one button for each data-* attribute.

The question is, must I use the format option, or should it be sufficient to have at least one of the four supported orthogonal data-* attributes?

colin

This is a quick example of using orthogonal data to get the class - http://live.datatables.net/kuqawedu/3/edit .

I was halfway through this then realised you probably didn't want it that way, but just in case, take a look and see if that works.

Another option, is in columns.render, the fourth parameter is meta, which contains the row and column numbers. You can use this with cell().node() to get the node for the cell, which you can then extract the data attribute, something like:

api.cell(meta.row, meta.col).node()).attr('data-export')

I hope one of those two approaches does the trick, if not, reply back,

Colin

ffe

Hm, solving the task with Javascript is not the problem. The forum post I linked to offers a solution with JS too. But in our case, it would be nice to solve it without much JS, as the initialisation seems to stay more general then.

Let me try to rephrase my question: Assume I use a data-order attribute like in my test case, and I also added the corresponding "exportOptions": { "orthogonal": 'order' } option to the button. Why doesn't the export button use the orthogonal data-order out of the box?

And thinking further, would it be a good idea to "officially" introduce a new orthogonal type "export", that is used for exports by default?

allan

Why doesn't the export button use the orthogonal data-order out of the box?

Because DataTables doesn't automatically detect all data-* parameters, just the ones that DataTables knows about. This is the code that does that.

There isn't actually a good way to handle custom attributes at the moment because we just use the default three types that the core uses. This is something we are going to need to think about to allow expansion without effecting speed.

And thinking further, would it be a good idea to "officially" introduce a new orthogonal type "export", that is used for exports by default?

We've thought about that - but the majority of the time the data folk want to export is what is seen in the table. Thus it defaults to display with the option to override it if required.

Regards,
Allan

ffe

Thanks Allan, your last post has pointed me in the right direction!

Because DataTables doesn't automatically detect all data-* parameters, just the ones that DataTables knows about. This is the code that does that.

I already suspected that - The original test case uses a known attribute ("order") and an unknown one ("export").

But now I realized, the key point is: What are the known data-* attributes? You say the default three sort, type, filter, but what about the aliases order and search? According to the documentation, I expected the aliases to be treated totally equal.

After changing my test case to some of the first three attributes, export works as expected: http://live.datatables.net/kuqawedu/5/edit?html,js,output

There isn't actually a good way to handle custom attributes [...] This is something we are going to need to think about to allow expansion without effecting speed.

Okay, a valid point

We've thought about that - but the majority of the time the data folk want to export is what is seen in the table. Thus it defaults to display with the option to override it if required.

Well I think this argument is valid for all of the existing orthogonal data: Most of the time, display is enough Maybe you can add it as feature request and we will be surprised some day in the future

To conclude my post, I am fine with using the supported data attributes (in contrast to custom attributes), as they will be sufficient most of the time in our case. But in my opinion, it is a bug that data-order and data-search are not supported currently. What do you think?

Thanks again for your support and keep up the good work!

allan

According to the documentation, I expected the aliases to be treated totally equal.

Yes, sorry I should of clarified that. The aliases are treated equally. The way it works internally is that the order is mapped to the sort type (likewise for the others) which is just a legacy thing to keep the code half way sane.

The result of that is that you still need to use the old style naming for the orthogonal option - e.g.:

 "orthogonal": 'filter'

event although the attribute might be data-order. I agree that is confusing and the orthogonal fetch should support the alias as well.

Regards,
Allan

ffe

Thanks for the clarification, Allan.

ffe

I agree that is confusing and the orthogonal fetch should support the alias as well.

Hi Allan, will it be added to one of the following releases?

allan

Added here: https://github.com/DataTables/DataTablesSrc/commit/aac7a53fa8e74b3594c69b90cd3356726a758d3d . I'll be tagging it up soon.

Allan

ffe

Thanks Allan!

samraj

Hi Allan can we use this for serverside processing? I have tried but it haven't worked. Can you kindly share an example to use data-* for serverside processing?

kthorngren

@samraj what exactly are you having a problem with? Here is an example of using data-order with server side processing.
https://live.datatables.net/pacugula/1/edit

Please update the test case to show us what you are having difficulties with.

Kevin

samraj

Hi @kthorngren My problem is with Exporting excel. I'm using serverside processing and to get the full data to export I'm using the following code :
var self = this;
var oldStart = dt.settings()[0]._iDisplayStart;
dt.one('preXhr', function (e, s, data) {
data.start = 0;
data.length = -1;
dt.one('preDraw', function (e, settings) {
$.fn.dataTable.ext.buttons.excelHtml5.action.call(self, e, dt, button, config, cb);
dt.one('preXhr', function (e, s, data) {
settings._iDisplayStart = oldStart;
data.start = oldStart;
});
setTimeout(dt.ajax.reload, 0);
return false;
});
});
dt.ajax.reload();

I want to use the data-* so that in some column I will be using some svg's. For I want to point to data-* instead of that svg.

allan

I've never tried it to be honest - if it does a draw, then yes, it probably will work, but if you link to a test case I can take a closer look. That said, I would strongly discourage using this method for export with server-side processing. If you are going to do that, you'd be as well just disabling server-side processing, since you need the full data set at the client-side. When server-side processing, you could create the Excel file server-side.

Allan