Implementing filters

Field filters are disabled for the custom data source API connection in Flexmonster by default. In the response to the /fields request, you can specify which filters to enable in Flexmonster and support on the back end.

The guide focuses on how to configure filters. Filters can be:

• Turned on all at once
• Configured separately for fields of a certain type
• Defined for each field individually

Available filter configurations

Filters can be configured through the following properties:

• members — configures the selection filter.
• query — configures the conditional filter.
• valueQuery — configures the value filter.

These configurations must be sent in response to the /fields request and can be applied to all fields, to fields of a certain type, and/or to certain fields.

Turn on all filters at once

To enable all available filters at once, set the filters property to true in the response to the /fields request:

"filters": true,

Note This approach requires implementing all the available filters in Flexmonster Pivot (see the list of supported filters).

Configure filters for fields of a certain type

You can enable filters for fields of a certain type. The filters must be specified in the filters property of the response to the /fields request.

Filters for any field type

The filters.any property allows configuring filters for fields of all types. For example:

"filters": {
  "any": {
    "members": true,
    "query": true,
    "valueQuery": true
  }
}

Here, the query is set to true, which enables all conditions supported by every field type: "equal", "not_equal", "between", "not_between". You can enable only some of these conditions by specifying them in an array:

"filters": {
  "any": {
    "members": true,
    "query": ["equal", "not_equal"],
    "valueQuery": true
  }
}

Note To use the "equal" and "not_equal" conditions for date fields, implement the "between" and "not_between" conditions on the server. Read more in the Conditions for the "date" field type section.

In the same way, the valueQuery property can be used to enable either all conditions supported by the value filter or only some of them:

"filters": {
  "any": {
    "members": true,
    "query": ["equal", "not_equal"],
    "valueQuery": ["top", "bottom"]
  }
}

Filters for fields of a certain type

The filters.string, filters.number, and filters.date properties allow configuring filters for fields of a corresponding type. Here is an example of filters configuration for the "string" field type:

"filters": {
  "string": {
    "members": true,
    "query": true,
    "valueQuery": true
  }
}

Here, the query is set to true, which enables all conditions supported by the "string" field type. You can enable only some of these conditions by specifying them in an array:

"filters": {
  "string": {
    "members": true,
    "query": ["equal", "not_equal"],
    "valueQuery": true
  }
}

In the same way, the valueQuery property can be used to enable either all conditions supported by the value filter or only some of them:

"filters": {
  "string": {
    "members": true,
    "query": ["equal", "not_equal"],
    "valueQuery": ["top", "bottom"]
  }
}

Filters for the fields of the "number" and "date" types can be configured similarly. See the list of supported conditions for the "number" and "date" field types.

Define filters for individual fields

Filters can also be configured for individual fields. This can be done by specifying the filters property for the necessary field. For example:

"fields": [
  {
    "uniqueName": "Country",
    // Other properties
    "filters": {
      "members": true,
      "query": ["equal", "not_equal"],
      "valueQuery": ["top", "bottom"]
    }
  }
],

Conditions that can be defined in the query property depend on the field's type. See the list of supported conditions for "string", "number", and "date" field types.

In the valueQuery property, you can specify which conditions are supported by the value filter.

Supported filtering conditions

Conditions for the value filter

Conditions for the value filter are common for all field types. The supported conditions are the following: "top", "bottom", "equal", "not_equal", "greater", "greater_equal", "less", "less_equal", "between", "not_between".

For the conditional filter, the supported conditions depend on the field type. Have a look at the list of supported conditions for "string", "number", and "date" fields below.

Conditions for the "string" field type

Filter by condition supports the following conditions for the "string" field type: "equal", "not_equal", "begin", "not_begin", "end", "not_end", "contain", "not_contain", "greater", "greater_equal", "less", "less_equal", "between", "not_between".

Conditions for the "number" field type

Filter by condition supports the following conditions for the "number" field type:  "equal", "not_equal", "greater", "greater_equal", "less", "less_equal", "between", "not_between".

Conditions for the "date" field type

Filter by condition supports the following conditions for the "date" field type: "equal", "not_equal", "before", "before_equal", "after", "after_equal", "between", "not_between", "last", "current", "next".

Note that the server always receives either "between" or "not_between" in the filtering request when the following conditions are applied to date fields:

• "equal"
• "not_equal"
• "last"
• "current"
• "next"

To use these conditions in Flexmonster, implement the "between" and "not_between" filters on the server even if they are disabled for the client.

What's next?

You may be interested in the following articles:

• Implementing the custom data source API server
• Returning data for the drill-through view
• Supporting more aggregation functions
• Supporting multilevel hierarchies