Inhibition of incorrect GET on initialisation when no URL is specified for an ajax specification?
Inhibition of incorrect GET on initialisation when no URL is specified for an ajax specification?
Hallo, all
My application needs to build a DataTable instance (by calling the DataTable(json)
API) without filling in the data, but showing all the colums, buttons and so on. The data are filled in later.
Until last week, I used a window.fetch(...)
call for the filling, and no ajax
, and everything worked as expected.
But last week I decided to use the ajax
and so added an ajax
JSON specification with no URL for the initialisation, arranged for the delayed loading of the data using dataTable.ajax.url(uri).load()
, and have spent more hours than I care to count trying to determine why my datatable is now sending 2 XHR GETs.
It turns out that the initialisation of the DataTable emits its own XHR GET, with an URL that looks like the window's own URL, even when no URL is specified in its ajax
specification. The data returned is (obviously, but confusingly to the datatable) the page's HTML, which causes an error in the filling of the datatable, this causing an alert(...)
. Dismissing the alert yields the (desired) empty table, and when the dataTable.ajax.url(uri).load()
is called, the correct URI is sent, the expected data are retrieved, parsed and loaded into the datatable exactly as expected
Is it possible to inhibit the first GET and not to attempt to retrieve data when building the (initially empty) datatable? I tried setting "url": null
, but that doesn't work any better :-(
IMHO, if no URL is specified on initialisation, no data should be retrieved at all, especially not with an URL that is guaranteed not to to return data the datatable can use...
Looking forward to your ideas on the subject.
TIA
Replies
Hold your horses...
It turns out that, in searching for the cause of an aborted GET, I disabled the abort that performs this inhibition...
My fault, then.
But I still think that setting up the URL for a send that never gets called, and using the abort to this end isn't very pretty.
Fixing the root cause would be better.
Would you agree?
It turns out, finally, that the problem still exists: this is because sometimes the datatable is initialised but never filled (by a server call) because it is known to be empty.
In that case, the GET is not aborted and the datatabel receives the HTML, with the expected, unwanted, result.
I suppose I could make an endpoint to return empty data, but that reminds me of bandaging a wooden leg.
Would it be possible to fix this?
And also, relying on a race condition to fix a problem is IMHO not good.
Hi,
I'm quite confused as to why you don't want the
ajax
option to send its initial data fetch request. The answer is that you can stop it using thepreXhr
something like this:However, I don't understand why you would want to do that? Perhaps you can link to a test case showing the underlying issue please?
Allan
A proposal to achieve this:
modify line 14 of this utility function as follows, adding a test for an URL:
In my version of datatables.js, the function starts at line 96436.
I'm still not clear on the use case. Before I make any changes I'd like to understand why it is needed. I don't understand why you would specify the
ajax
option if you aren't using the built in Ajax?Allan
I've been looking over our bug list today and one caught my attention which I think is basically asking the same as your own. Don't make an ajax request if the url is given as an empty string. Then, later the DataTable can be populated using
ajax.url().load()
(presumably based on user data).I've committed that into my DataTables 2 branch and it will be included in DataTables 2.
Allan