Update: Passing jqXHR for dataSrc in ajax. - #337

Interesting one. Thanks for the pull request. I'm not going to pull this in immediately, as I want to think a little bit about ajax.dataSrc and how it might be used with the records found, etc, parameters. This is a nice suggestion for improving the flexibility of the dataSrc option, and I wonder if I can find a way of taking it further... I've got a bit of a back log at the moment though, so it might take a little while before I can get to it.

I'm in a situation where I need to grab this metadata (total, etc.) from headers. Is this patch by @JuarezTurrini still the best/only way to accomplish this?

I notice that the xhr event callback now accepts a fourth parameter, the jqXHR object. It seems appropriate and timely that the dataSrc callback would also take the jqXHR object as a parameter now.

I'm not sure whether this is intentional or a bug, but as I'm testing the xhr event, I'm noticing that the language.info strings are not getting updated after the event callback executes.

I'm not sure whether this is intentional or a bug, but as I'm testing the xhr event, I'm noticing that the language.info strings are not getting updated after the event callback executes.

This is expected yes. The Ajax request to get the language strings (I presume you are using language.url?) effectively operates its own Ajax request - it does not trigger an xhr event itself. This is something I want to address, but it is going to take a significant amount of work I suspect.

(No, I'm not using language.url, but I am setting language.info, language.infoEmpty, and language.infoFiltered. In the xhr event callback, I massage the data with headers I retrieve through the jqXHR object; after the data has been massaged into the format that DataTables likes, and the callback has completed, and the table is filled with data, the language.infoEmpty string is still being shown—even though the data is not empty—and the language.infoFiltered string shows NaN instead of __MAX__.

Obviously this is all wrong. I could try to debug it out, but it seems that the preferred solution would be to access the jqXHR object in the dataSrc callback instead of working with the xhr event at all.)

No, I'm not using language.url, but I am setting language.info, language.infoEmpty, and language.infoFiltered. In the xhr event callback

Okay - thanks for the clarification. Unfortunately that will not work at the moment. There is currently no way to dynamically change the language strings that DataTables uses after initialisation and the language strings have already been set up by that point.

As a followup to this thread, I've successfully met my goals (of needing to grab metadata from the headers) with the xhr event callback. (I had some problems BCAK, mostly having to do with the fact that the data parameter in the callback needs to be modified in-place, not returned.)

I still think that the jqXHR parameter should be added to the xhr event signature, because (as I understand it) the event is intended to be orthogonal to the dataSrc option (when a function). But this shouldn't stop anyone cold.

Thanks, @DataTables, for the quick feedback, and for the codebase itself, which has been amazing.