The UI filters are disabled for the custom data source API connection in Flexmonster by default. You can choose which filters to enable in Flexmonster and support on the back end. This filter configuration can be done in the schema and the filtering itself should be implemented in the query.filter
part of the /select request.
The guide focuses on how to configure filters. Filters can be:
There are three properties in the /fields request through which filters can be configured:
members
(optional) – Boolean. Configures an include/exclude members
filter. If true
, the members
filter is enabled in Flexmonster Pivot.query
(optional) – Boolean|Array of strings. Configures a conditional filter on members. This filter can be turned on either by setting the property to true
or by specifying an array of supported conditions.true
, it enables all the conditions that exist in Flexmonster Pivot for the members
filter. See the list of supported conditions for “string”, “number”, and “date” field types.valueQuery
(optional) – Boolean|Array of strings. Configures a conditional filter on values. This filter can be turned on either by setting the property to true
or by specifying an array of supported conditions.true
, it enables all the conditions that exist in Flexmonster for the values filter. See the list of supported conditions.These configurations can be applied to all fields, to fields of a certain type, and/or to certain fields.
Turning on all filters at once is the simplest way to enable filtering. To enable all available filters, set the root filters
property of the /fields request to true
:
"filters": true,
This approach requires implementing all the available filters in Flexmonster Pivot (see the list of supported filters).
It is possible to specify the supported filtering conditions for fields of a certain type. This can be done in the root filters
property of the /fields request.
Filters that are common for all the field types can be defined by specifying the filters.any
property:
"filters": {
"any": {
"members": true,
"query": ["equal", "not_equal"],
"valueQuery": ["top","bottom"]
}
}
Here, the query
property can contain only "equal"
, "not_equal"
, "between"
, and "not_between"
conditions since these are the only conditions that are common for all the field types.
In the valueQuery
property, you can specify which conditions are supported by the filter on values.
The string
, number
, and date
properties allow you to configure filters for fields of a corresponding type. Here is an example of filters configuration for the "string"
field type:
"filters": {
"string": {
"members": true,
"query": ["equal", "not_equal"],
"valueQuery": ["top", "bottom"]
}
}
Here, the query
property can contain conditions that are supported by the “string” field type.
In the valueQuery
property, you can specify which conditions are supported by the filter on values.
Filters for the fields of the "number"
and "date"
types can be configured similarly. See the list of supported conditions for “number” and “date” field types.
Filters can also be configured for individual fields. This can be done by specifying the fields.filters
property:
"fields": [{
//other properties
"filters": {
"members": true,
"query": ["equal", "not_equal"],
"valueQuery": ["top", "bottom"]
}
}],
In the valueQuery
property, you can specify which conditions are supported by the filter on values.
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.
Conditions for the filter on values 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 members
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.
The filter on members 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"
.
The filter on members supports the following conditions for the "number"
field type: "equal"
, "not_equal"
, "greater"
, "greater_equal"
, "less"
, "less_equal"
, "between"
, "not_between"
.
The filter on members supports the following conditions for the "date"
field type: "equal"
, "not_equal"
, "before"
, "before_equal"
, "after"
, "after_equal"
, "between"
, "not_between"
, "last"
, "current"
, "next"
.
After configuring the filters in the schema, the handling of the query.filter
part of the /select request should be implemented.
Note that the server always receives either "between"
or "not_between"
in the filtering request when Flexmonster Pivot uses the following date filters:
"equal"
"not_equal"
"last"
"current"
"next"
To use these date filters on the client, implement the "between"
and "not_between"
filters on the server.
You may be interested in the following articles: