Open GoogleCodeExporter opened 9 years ago
Original comment by joc...@gmail.com
on 29 Feb 2012 at 6:11
[deleted comment]
[Comment deleted and re-created to fix a typo, Michael]
We tried to fix the problem by implementing a simplified and less powerful
solution by ourselves, using self-provided textbox-only input boxes and key
handlers, eliminating the columnFilter plugin.
We followed the description found here:
http://datatables.net/examples/api/multi_filter.html
... and pursued all the hints from the referenced forum thread found here:
http://datatables.net/forums/discussion/2864/x#Item_3
Funny enough, we ran into *exactly* the same behavior as experienced with
columnFilter. I take this as an indication, the problem does not originate from
columnFilter plugin but is a design flaw in the datatables interface: the
sSearch_0, _1, ... data should not be forwarded to server side filtering as an
integer indexed arrary (only) but (optionally) as a dictionary, mapping
mDataProp column names to filter strings.
This way any ambiguity as to what filter belongs to what column could be
avoided, and any errors in colReorder, colVis, columnFilter or datatables
itself became more easy to identify, locate and ultimately, to fix. You'd see
directly from the json what went wrong with no need to match array positions to
switched columns.
Jovan, I will introduce this idea to the datatables team, would you consider to
support it?
Michael Böhnisch
Original comment by Michael....@gmail.com
on 9 Mar 2012 at 7:59
> the sSearch_0, _1, ... data should not be forwarded to server side filtering
as an integer indexed arrary (only) but (optionally) as a dictionary, mapping
mDataProp column names to filter strings.
DataTables will also send the mDataProp_{} value for each column to allow the
mapping to occur. It is done this way in order to ensure backwards
compatibility with server-side processing libraries which were created before
mDataProp was introduced.
There is an example server-side processing script which uses this here:
https://github.com/DataTables/DataTables/blob/master/examples/server_side/script
s/objects_jsonp.php . As you can see it simply needs to look the column index
up in the mDataProp to determine the correct index. There needs to be a mapping
somewhere, and this is the method used in DataTables.
It is worth noting that this is only applies to server-side processing. If
client-side processing is used then sSearch_{} etc has no relevance.
Original comment by allan.ja...@gmail.com
on 9 Nov 2012 at 6:52
I was having the same issue, i got around it with some help from
http://www.thenameiskhan.com/custom-filter-state-saving-datatable
Each of the fnCreates had to be altered to lookup the stored value
e.g.
function fnCreateSelect(aData) {
var index = i;
var oSettings = oTable.fnSettings();
var preVal = oSettings.aoPreSearchCols[i].sSearch;
var r = '<select class="search_init select_filter"><option value="" class="search_init">' + label + '</option>', j, iLen = aData.length;
for (j = 0; j < iLen; j++) {
if (aData[j] === preVal) {
r += '<option value="' + aData[j] + '" selected="true">' + aData[j] + '</option>';
} else {
r += '<option value="' + aData[j] + '">' + aData[j] + '</option>';
}
}
or
function fnCreateInput(regex, smart, bIsNumber) {
var oSettings = oTable.fnSettings();
var preVal = oSettings.aoPreSearchCols[i].sSearch;
var lbl = label;
var viewclass = '';
if (!preVal) {
viewclass = 'search_init';
} else {
lbl = preVal;
}
var sCSSClass = "text_filter";
if (bIsNumber)
sCSSClass = "number_filter";
var input = $('<input type="text" class="' + viewclass + ' ' + sCSSClass + '" value="' + lbl + '"/>');
Original comment by csakka...@gmail.com
on 12 Dec 2012 at 12:26
Original issue reported on code.google.com by
Michael....@gmail.com
on 28 Feb 2012 at 7:24