(SearchBuilder) "serverData" breaks the expected behavior when updating data select

mtdev

In SearchBuilder, using the "serverData" implementation breaks the expected behavior when updating the "data" select on the fly

Link to test case: http://live.datatables.net/boqemuni/15/edit

Context

In SearchBuilder, with a server-side implementation, I would like the filter "values" field of some columns can be displayed in a SELECT and not aN INPUT. Input is the default behavior with ajax/server-side, because all available values are unknown...

... but the solution is already a component feature

Ready to develop a feature, I have seen there is already something in place : serverData in JSON response can bring the options to display into the value filter, as a HTML SELECT.

An example

Based on example data, if I want the "Office" filter to be displayed as a SELECT, I have to add into JSON response a searchBuilder.options key, with data (example with 2 values):

json.searchBuilder.options = {
    'office': [
        {
            value: 'jp-tok',
            label: 'Tokyo'
        },
        {
            value: 'uk-lon',
            label: 'London'
        }
    ],
};

What I expect

When I add a condition, and select a data (other than "office") and the condition "equals" , the value field is a input (at its first display). If I change the data to "office" I the value field becomes a SELECT (with the serverData as options). And if I change the data field to another field again, I expect the value field becoming an INPUT.

In the same way, if I first select as data the office I expect a SELECT, which will be change into INPUT if change the data.

What happens / Issue

Above all :
* All data type (columns) are defined as "string"
* I use in the example the "predefined" configuration to avoid changing the "condition" field in each test. Without this configuration, there is the same issue.
* I use an event to add the serverData into JSON, for an easy way to reproduce.

The two cases in the live.datatables :

Case 1 : Add condition > select First name : value field is an INPUT. Change data to Office : the value field is still a INPUT. No way to get the SELECT.

Case 2 : Add condition > select Office : value field is a SELECT. Change data to First name : the value field is still a SELECT, with empty values because there is no serverData related to this field. No way to get the INPUT.

Some ideas / explanation

It seems related to the type for the data (data type of the column). In the live example (version 15), all fields are string and the issue occurs on every field.

In the version 16 of the live example (http://live.datatables.net/boqemuni/16/edit), the issue is the same on string fields (first name, last name and office), but the two last data (start_date and salary) have an other type, respectively date and num : in this case, when switching the data from one of these updates both the condition and field type as expected..

Question

Seems to be an issue, right ?

Do you have an idea how to fix this issue, even temporarily in the current code ?
I thought about adding a new type, with a string inheritance, to avoid the issue, but perhaps its simpler to edit some existing code.

Regards,

mtdev

Erratum : the real Link to test case : http://live.datatables.net/boqemuni/17/edit , with only a 'string" type for all columns.

The second link to test case http://live.datatables.net/boqemuni/16/edit is OK with the "date" and "num-fmt" on two other columns to see the behavior when switching betweend different types.

mtdev

Awaiting an answer which could be an existing solution or an idea of fix, I use the next workaround to avoid the issue which does not update the value field when the column type is the same when changing the "data field".

Adding a global new condition type, which is exactly the same as "string" :

$.fn.dataTable.ext.searchBuilder.conditions.stringlist = $.fn.dataTable.Criteria.stringConditions;

Then defining the type of the column which would have a list definition :

    options.columnDefs = [
        {
            'targets': [2],
            "type": "stringlist"
        }
    ];

Result : link to test case : http://live.datatables.net/boqemuni/18/edit where the value field changes when we switch between "data" which have a "stringlist" type and the other types.