Skip to content
Filter
This guide will provide an overview and examples of working with data filters in Molten UIs.
Overview
To search the Leverege platform for data – as opposed to requesting a list of data or making a get request for a specific item – we pass an Imagine filter in to the search endpoint. This filter tells the API what properties of data to select for: where such-and-such a field (i.e., value at an attribute path) equals such-and-such a value, or not this, etc. Leverege’s search is backed by elasticsearch, and supports almost all of the query operations familiar in that platform (though Leverege uses a different query syntax).
The Imagine filter is a plain JSON object that simply encodes the query structure. For example, the following filter will search for devices along where the device’s data.company.name field matches one of the two given strings:
{
"type":"equals",
"field":"data.company.name",
"value":[
"Penguin Parcels",
"Orca Operations"
]
}
Searches can be performed along an interface path to restrict the search space (e.g., api.interface( systemId, ‘continent' ).obj( continentId ).grp( 'packages' ).search( imagineFilter ) would search only children of the given continent’s packages relationship.
Filter Types
Type
Description
Keys
Key Type
Key Description
Default Value
Type
Description
Keys
Key Type
Key Description
Default Value
Exists
3
Filters the data based on whether or not the provided field is defined
3
type
string
‘exists’
field
string
determines which field the filtering will be performed on
not
boolean (optional)
if true will filter for null values, if false will filter for non null values.
If using not the filter must be nested in a logical filter.
false
Comparison
6
Filters the data based on the provided comparator and values. Can be used for dates and numbers
6
type
string
'comparison’
field
string
determines which field the filtering will be performed on
comparator
string
<, >, <=, >=, (), (], [), []
value
number or date
value to be used for comparison
value2
number or date (optional)
if comparator is (), (], [), [] will be used as the less than value
isDate
boolean (optional)
must be supplied as true if the field is a date
false
Equals
5
Filters the data based on the provided value.
5
type
string
‘equals’
field
string
determines which field the filtering will be performed on
fieldType
string
the field type of the field that the filter is being done against.
string
value
fieldType or array of fieldType
value to be used for filtering
not
boolean (optional)
if true will filter for items that don’t equal the value, if false will filter for items that equal the value.
If using not the filter must be nested in a logical filter.
false
Expression
8
Filters a string field based off of the provided expression
8
type
string
'expression’
field
string
determines which field the filtering will be performed on
kind
string (optional)
the type of filter to perform, can be ‘match’, ‘regexp’, ‘wildcard’ or ‘queryString’
match
value
string
value to be used for filtering
no
ignoreCase
boolean (optional)
if true, will ignore casing when filtering
false
analyzeWildcard
boolean (optional)
attempts to analyze wildcard terms in the query string, used with a queryString
false
defaultOperator
string (optional)
determines if multiple terms in a queryString should be search with ‘and’ logic or ‘or’ logic, defaults to ‘or’
or
GeoDistance
5
Filters a geo attribute based on the location and distance provided
5
type
string
'geoDistance’
field
string
determines which field the filtering will be performed on
location
geo point
the location to perform the filter against
fieldType
string (optional)
the type of field the filter is against
geoPoint
GeoPoint
3
Finds all geo points within the provided polygon
3
type
string
'geoPoint’
no
field
string
determines which field the filtering will be performed on
no
points
array of geopoints
Points that make a polygon that will filter the points
no
GeoShape
7
Finds all the geoshapes with the given relationship to the provided geoshape
7
type
string
‘geoShape’
field
string
determines which field the filtering will be performed on
relation
string
intersects, contained, within or disjoint.
shape
geoshape (optional - either shape or shapeType and coordinates must be provided)
Shape that the filter will be performed against
shapeType
string (optional - either shape or shapeType and coordinates must be provided)
type of shape that should be made with the coordinates
coordinates
array of geopoints (optional - either shape or shapeType and coordinates must be provided)
With ShapeType is used to make the shape to filter against
dataType
string (optional)
data type of the field
geoshape
Logical
3
Combines other filters together to allow for more complex filtering
3
type
string
'logical’
operator
string
'and’ or ‘or’
conditions
array of filters
the filters that will be checked against
Working with Filter Models
Models
In Molten UIs, filter instances are typically constructed based on filter models. Models are templates, in this case templates for the various filtering operations the endpoint will accept.
Simple Filter Model
To quickly create an equals filter without having to code in the boilerplate, we can call EqualsFilterModel.create(), which yields:
{
"type":"filter.equals",
"field":null,
"value":[],
"empty":false,
"fieldType":null
}
Models typically include setters and getters for their properties: e.g., setField( ‘foo’ ), getField().
Types of Filter Models
Molten has Filter models and editors for Comparison, Equals, Exists filters, in addition to equals models and editors based on enums. The models contain all the information detailed , with getters and setters for each field. There is one exception in isDate on Comparison filters. Filter models are created with attributes, and the isDate field is dependent upon a date type field being supplied to the filter model.
The models are immutable, and using the setters will return a new instance of the model, with the updated field.
In addition to this, models feature a toImagineFilter method that will return an instance of the filter formatted so be send to the Leverege api. Molten saves the filters that are applied on it to the url parameters. In addition, it reads queries from the url parameters. This allows for filters to be saved through refreshes, in history, and for redirections to have filters pre-applied.
Source Models
Filter objects created from these basic models are sufficient for the backend services that need to find data. But they do not always encode enough information for the frontend UIs that need to construct the queries.
Suppose you are working with a Molten UI and looking at a Group Screen that shows a table, a map, and a search bar. Each of those components can contribute to the filter: the table provides column filters (this attribute equals one of these selected items), the map may filter by the currently selected floor of a building, and the search bar provides a free text search of the relevant data. While the backend only cares about the combined filter, the UI needs to know the individual components so it can, e.g., show the correct status of the table filter buttons.
To do this, Molten uses models that encode information about the source of the filter: a FilterSourceModel (a single source’s contribution) and FilterSourcesModel (a combination of filters from various sources).
In most cases, your component will only need to create a FilterSourceModel instance for its individual contribution to the Group Screen filters, and call a onFilterChange method passed down from the Group Screen. The Group Screen will handle the combination operations.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.