Field filters are disabled for the custom data source API by default. In the response to the /fields request, you can specify which filters to enable in Flexmonster and support on the back end.
This guide focuses on how to configure filters.
Filters can be configured through the following properties of the FilterConfigObject:
These configurations must be sent in the response to the /fields request. They can be used to configure filters for all fields, for fields of a certain type, or for individual fields.
All filters can also be enabled at once for all fields.
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 filters available in Flexmonster Pivot.
You can configure filters for all fields or for fields of a certain type. In this case, the filters property of the response to the /fields request should be specified as an object.
To configure filters for fields of all types, use the filters.any property.
If you want to support all filtering configurations available in Flexmonster for all field types, set filters.any
to true
:
"filters": { "any": true }
To configure filters separately, specify filters.any
as the FilterConfigObject. For example:
"filters": { "any": { "members": false, "query": true, "valueQuery": true } }
Here, the query is set to true
, which enables all conditions for each field type: "string", "number", and "date".
You can also explicitly specify supported filtering conditions in an array. Note that in this case, only conditions common for all field types can be specified:
"filters": { "any": { "members": false, "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": { "any": { "members": false, "query": ["equal", "not_equal"], "valueQuery": ["top", "bottom"] } }
The filters.string, filters.number, and filters.date properties allow configuring filters for fields of a corresponding type. These filter configurations override configurations set for all fields in filters.any
.
We will showcase filter configuration on an example of the "string"
field type. If you want to support all filtering configurations for fields of this type, set the filters.string
property to true
:
"filters": { "string": true }
To configure filters separately, specify filters.string
as the FilterConfigObject. For example:
"filters": { "string": { "members": false, "query": true, "valueQuery": true } }
Here, the query is set to true
, which enables all conditions supported by the "string" field type.
You can also enable only some of the conditions by specifying them in an array:
"filters": { "string": { "members": false, "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": false, "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.
Filters can be configured for individual fields by specifying the filters property for the necessary field. Filter configurations for individual fields override configurations set for all fields and for fields of a certain type.
Here is an example of a filter configuration for an individual field:
"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.
The value filter supports the following conditions: "top"
, "bottom"
, "equal"
, "not_equal"
, "greater"
, "greater_equal"
, "less"
, "less_equal"
, "between"
, "not_between"
.
These conditions can be specified for fields of all types.
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.
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"
.
Filter by condition supports the following conditions for the "number"
field type: "equal"
, "not_equal"
, "greater"
, "greater_equal"
, "less"
, "less_equal"
, "between"
, "not_between"
.
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 side.
The following conditions of the conditional filter are common for all field types:
"equal"
"not_equal"
"between"
"not_between"
Use them when specifying supported filters for all fields in the filters.any
property.
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.
You may be interested in the following articles: