I just fell into a situation where the currently available set of values for type
seems not enough to work as simply as it'd be possible.
Here is a pretty simple use case that illustrates the problem.
Having a column (say "allowed") containing a boolean value, which contains "0" or "1" (comes from a DB content).
Obviously it needs to be more friendly displayed so we'll do something like this:
var table = $('#example').dataTable({
columnDefs: [{
data: 'allowed',
render: function (data, type, row, meta) {
return data == '1' ? 'yes : 'no';
}
}]
});
Since we didn't do anything depending on type
above, the user can type "yes" or "no" in the dedicated filter area to display only the allowed (respectively not-allowed) rows .
In the other hand, if for some reason the application must directly filter rows by itself, we can do for instance:
table.columns(<col index>).search('yes').draw;
So far so good.
Now if the application works in a multilingual context where a localize()
function is available, the first scriptlet above becomes:
var table = $('#example').dataTable({
columnDefs: [{
data: 'allowed',
render: function (data, type, row, meta) {
return localize(data == '1' ? 'yes : 'no');
}
}]
});
Then user filtering keeps working fine, wether using "yes|no", "si|no", "oui|non", and so on.
But... now application filtering works only when the current language is English!
So one immediate obvious solution is to also change the second scriptlet accordingly:
table.columns(<col index>).search(localize('yes')).draw;
Sure then it works fine anew, but here is what I wanted to expose: isn'it too bad to have to use localize()
again, while in this case a more immediate and elegant method would be to directly work with the original data value "0|1":
table.columns(<col index>).search('1').draw;
For this to work, it'd suffice to make render()
work depending on its type
argument.
But it's not currently possible: the "filter" type
is the one used by DataTables both when responding to user-filtering and to column.search()
.
(BTW I guess that maybe user-filtering just uses column.search()
...)
Here we retrieve what the doc says about the filter|search ambiguity.
So it'll be great if it could be uncoupled (may be by adding a new type
value "search"?).
Thanks for your attention.