Override default AJAX error behavior

Gideon

Hi, datatables team:

I'm using a server side datatable. There are two types of error that I want to trap:

1. Server-side error - e.g. There is an error 404, 500 etc. or a malformed/unparseable JSON has been returned.
2. Forced error - e.g. The request is successful and also returned a valid JSON. But a property called error is included to the response to force the datatable to treat it as if it is an error, even though the response is successful. (that's why the error property should only be included if there is REALLY an error, as stated on the documentation)

Both flashes the error message on alert box. But I want to do another approach aside from alert boxes. Is there a callback function for this? The error.dt event seems able to override the default behavior for number 1. But what about number 2? As a working example:

    {
        aaData: [],
        draw: "6",
        error: "↵Please fill up first all the fields to perform an inquiry.",
        iTotalDisplayRecords: 0,
        iTotalRecords: 0,
        sEcho: null,
    }

When the above JSON response has been returned, it will flash an alert message indicating:

Please fill up first all the fields to perform an inquiry.

What I want instead is to use that error string on something else, e.g. put on a div.panel, etc..

Thank you very much. Please keep up the good work on making a great plugin!

allan

For the second, you can use $.fn.dataTable.ext.errMode set to be a function what will do whatever error handling you need. For some reason I've documented it as part of error, which I'll fix shortly, but there is at least some documentation available :-).

Allan

Gideon

Hi, allan:

Thanks for the swift response.

Correct me if I'm wrong; but will this affect all the initialized Datatables? I'm thinking of a non-global setting for each table that has different behavior when they encounter an error.

allan

You are correct - this is a global configuration.

At the moment this is really the only way. I wonder if I should make the error event cancellable. That would, at least on initial thought, seem to solve the issue. You would add an event listener and then return false from it. I'm not immediately seeing any downsides...

Regards,
Allan