Simpler, shorter URLs for server-side datatables

tacman1123

We're using datatables to display survey results, and it no longer works for medium-size surveys because the URLs are so long for a 60-column response. It's also difficult to debug.

A couple of solutions that would simplify things. Certainly it'd be nice if empty (or default) columns weren't sent. If the table isn't sorted, or is only sorted on one column, wouldn't it be cleaner to just send that column info? Seeing bRegex_30=false for every column is just a waste of bandwidth, and in this case, it prevents more important data from being sent.

Speaking of columns, I'd be thrilled if the system would send the column identified rather that a column number. I would love to see zip=20009 in the url, instead of sSearch5=20009&mPropData5=zip

This has become fairly important to us, since we just crossed some threshold, probably moving out of testing small surveys and into "real world" ones we've discovered this show-stopper.

Suggestions on a short-term fix? Any chance for a longer-term, more elegant solution?

Tac

GregP

I'll throw in my comment that I'd also like to see the number of parameters put on a diet. I haven't gone as far as analyzing what our needs would be, but I know that I don't need any of the bRegex, and I'm not 100% sure what bSortable gives to the server; if sorting is restricted on the client side, I don't mind if someone thinks they're being clever by injecting the parameter because my server is just going to reject it.

Sending only the TRUE bSearchable columns would help slim it down, and I have also had some mapping issues in translating mDataProps and iSortCol into something the server can use (where something like "iSortCol_0='foo'" nstead of "iSortCol_0=3"would've been simpler).

I certainly don't intend to bellyache; on the contrary, all of my problems have been solved by using the existing API, which is a testament to its strength. But I do think that there are improvements that could be made in server-side processing.

As for the pure length of the URL; if you change the request method to POST instead of GET, are all the parameters still sent? I don't believe POST will have the same character-length restrictions as GET.

kcivey

A short-term fix is in your options to set a fnServerData that's basically a copy of the default function except that it uses POST for the request:
[code]
fnServerData: function (url, data, callback, settings) {
settings.jqXHR = $.ajax({
url: url,
data: data,
type: 'POST',
success: function (json) {
$(settings.oInstance).trigger('xhr', settings);
callback( json );
},
dataType: 'json',
cache: false,
error: function (xhr, error, thrown) {
if (error == 'parsererror') {
alert( "DataTables warning: JSON data from server could not be parsed. "+
"This is caused by a JSON formatting error." );
}
}
});
},
[/code]
I also don't see the purpose of sending "sortable" and "searchable" parameters to the server. It seems that if the server-side code gets parameters telling it to search or sort by something it shouldn't, it should refuse to do that even if it gets "sortable" or "searchable" parameters telling it otherwise.

AussieInSeattle

similar comment to kcivey - I managed to reduce my url from 579 bytes to just 130.
I construct my own data using what I am passed in - I dont use the built-in filtering as I pass those parameters in th querystring (data) myself.
If anyone knows an easier way to get sEcho, please let me know.

[code]
"fnServerData": function (url, data, callback, settings) {
//clean up data and apply our server params
//dl = displayLength, ds=DisplayStart, sb=SortBy (e.g 0|asc, 3|desc, etc), sEcho
//get the sEcho value first - not sure where it is stored
var sEcho = '';
for (var i = 0; i < data.length; i++) {
if (data[i].name == 'sEcho') {
sEcho = data[i].value;
}
}
data = [];
data.push({ "name": "dl", "value": settings._iDisplayLength });
data.push({ "name": "ds", "value": settings._iDisplayStart });
data.push({ "name": "sEcho", "value": sEcho });
data.push({ "name": "sb", "value": settings.aaSorting[0][0] + '|' + settings.aaSorting[0][1] });
//add our custom params
data.push({ "name": "CustomFilterName", "value": "CustomFilterValue" });

settings.jqXHR = $.ajax({
"url": url,
"data": data,
"success": function (json) {
$(settings.oInstance).trigger('xhr', settings);
callback(json);
},
"dataType": "json",
"cache": false,
"error": function (xhr, error, thrown) {
if (error == "parsererror") {
alert("DataTables warning: JSON data from server could not be parsed. " +
"This is caused by a JSON formatting error.");
}
}
});
},
[/code]

svr

same problem here. does anyone know which gateway-setting / networksetting is responsible for that max length in url? i need to have 70+ columns and there is now way to reduce the lenght of the url ... would be good to try changing gatewaysettings first.

stefan