how to display server-side status messages

carteriii

Is there a recommended way to display server-generated status or error messages to the user? For example, let's say a SQL query fails, or that the user doesn't have permission to select from a given set of data. Setting aside whether it's appropriate to display such a message to the user, if I return that error in the json message to datatables, how could I display it?

One solution would be to return an empty resultset in the json but include an additional element such as "status" or "message" in the json and do something with that on the client side. If I took that approach, how & where should I try to catch that "status" or "message" element in the normally processing of events for DataTables?

Alternatively I've thought about simply returning the status message in a normal row in the json message to be displayed, but ideally I'd return and display one big td element with the message and a colspan that is the full width of the table. Unfortunately if I do that, DataTables generates an error that the number of column returned by the server don't match.

Rather than using my initial suggestion of an additional status/message element in the json, is there a good way to return a single td element that can span the width of the table without generating an error message that the number of columns is incorrect?

I'm open to any suggestion to display server-side messages to the user, whether those be displayed inside or outside the table. Thanks.

carteriii

I just found the sEmptyTable and sZeroRecords strings. I tried just setting that in my json return, but that caused another problem. I'm debugging that, but if I can return sEmptyTable and/or sZeroRecords from the server, that will be a nice mechanism for returning generic status messages. Should I be able to set sEmptyTable and sZeroRecords from the server?

carteriii

I tried setting sEmptyTable, oLanguage.sEmptyTable, sZeroRecords, and oLanguage.sZeroRecords in my json return, but they did not override the default values. Is this possible, or perhaps that's a reasonable feature request for some future release?

carteriii

I'm stumped. Is there a way to set sEmptyTable or sZeroRecords from the server by returning something in the json?

allan

Interesting idea - what you could do is make use of fnServerData ( http://datatables.net/usage/callbacks#fnServerData ) to effectively intercept the return from the server (so another property in the JSON for your string) and set the values of the language strings in the table's settings object as needed. For example oSettings.oLanguage.sInfoEmpty = json.whatever;

Allan

jeresiv

Can you post an example of using the fnServerData with sInfoEmpty?

jnrj

Can somebody offer an example of modifying sInfoEmpty in fnServerData callback?

fbas

This works:

[code]
$(document).ready(function() {
var oTable = $('#example').dataTable( {
"sAjaxSource": "data_source.php",
"fnServerData": function ( sSource, aoData, fnCallback ) {
/* Add some data to send to the source, and send as 'POST' */
aoData.push( { "name": "my_field", "value": "my_value" } );
$.ajax( {
"dataType": 'json',
"type": "POST",
"url": sSource,
"data": aoData,
"success": function (data, textStatus, jqXHR) {
oTable.fnSettings().oLanguage.sInfoEmpty = data.sMsg;
oTable.fnSettings().oLanguage.sEmptyTable = data.sMsg;

fnCallback(data, textStatus, jqXHR);
}
} );
}
} );
} );
[/code]

in your server script, add a sMsg to the $output array:
[code]

/*
* Output
*/
$output = array(
"sMsg" => $sMsg, // <---- you can add any elements you want to the return JSON
"sEcho" => $sEcho,
"iTotalRecords" => $iTotal,
"iTotalDisplayRecords" => $iFilteredTotal,
"aaData" => array()
);

[/code]

jnrj

fbas: thank you for the example, it greatly helped.

fbas

Your welcome. The JSON return from the server side-script can hold anything (serialized) you want, which is useful for debugging (for example, you can return the $sQuery, if your script makes it that far - I don't use that inside my program, but it's helpful for the debugger's XHR viewer) or informing other parts of your client-side script. I guess Allan's site was just missing an example of collecting that data within the client-side script.