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?

ghherlinghherlin Posts: 20Questions: 3Answers: 0

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 ajaxspecification. 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

  • ghherlinghherlin Posts: 20Questions: 3Answers: 0

    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?

  • ghherlinghherlin Posts: 20Questions: 3Answers: 0

    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?

  • ghherlinghherlin Posts: 20Questions: 3Answers: 0

    And also, relying on a race condition to fix a problem is IMHO not good.

  • allanallan Posts: 63,489Questions: 1Answers: 10,470 Site admin

    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 the preXhr something like this:

    $('#example')
      .one('preXhr.dt', function () {
        return false;
      })
      .DataTable({
        ajax: '...'
      });
    

    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

  • ghherlinghherlin Posts: 20Questions: 3Answers: 0

    A proposal to achieve this:
    modify line 14 of this utility function as follows, adding a test for an URL:

    /**
         * Detect the data source being used for the table. Used to simplify the code
         * a little (ajax) and to make it compress a little smaller.
         *
         *  @param {object} settings dataTables settings object
         *  @returns {string} Data source
         *  @memberof DataTable#oApi
         */
        function _fnDataSource ( settings )
        {
            if ( settings.oFeatures.bServerSide ) {
                return 'ssp';
            }
            else if ( (settings.ajax && settings.ajax.url != null) || settings.sAjaxSource ) {
                return 'ajax';
            }
            return 'dom';
        }
    

    In my version of datatables.js, the function starts at line 96436.

  • allanallan Posts: 63,489Questions: 1Answers: 10,470 Site admin

    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

  • allanallan Posts: 63,489Questions: 1Answers: 10,470 Site admin

    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

Sign In or Register to comment.