Type to start searching...
Filter elements centralize the search configuration for a given class and are used by filter controls to present text search, filter tiles, and filter chips to end users.
Filters centralize the search configuration for a given class. If more than one .filter file is defined for the same class, their definitions are merged. Subclass-specific filters can be introduced using the base property.
A filters main parts are the text property, fields, and subjects.
The text property specifies the class attribute to use for text searches. This may be a calculated attribute that is used for full text search functionality.
The fields collection specifies what attributes are available for filtering. These fields appear as filter chips. An attribute can only have one field defined for it. e.g. you could not have two fields on the Entity class filter that are bound to the same firstName attribute. That said, the definition for that field may be overridden in a subclass filter.
Filters may also contain subjects (aka subject areas) that allow you to further segment instances based on sub-class or criteria. e.g. "Contacts and Companies" or "Clients" or "Prospects". At runtime, these subject areas may be used as the basis - potentially along with other criteria - for new filters that appear as filter tiles. Subjects contain an optional collection of filters which are simply a set of pre-defined filters (yes - a bit confusing and not the same thing as the filter elements we have discussed so far). In the UI, we simply have filters displayed as filter tiles, which are based on a subject area and may have additional criteria added through filter chips.
A typical portlet configuration contains a search layout (see below) with a single filter control followed by a list layout.
Filter controls are re-usable composite views that filter lists and navigators and are made up of sets of cards, chips, and a text search area as seen in the top of the image above.
<Layout class="Entity">
<Composite name="composite">
<Filter name="filter"/>
</Composite>
</Layout>
This configuration of a layout is called a Search Layout.
The important thing here is the search layout's class binding - in this case Entity. The filter control looks for all Filters that have a class property that matches it's layout's class binding - again, in this case Entity.
In portlets, search layouts are always configured with query="true" and are placed before, and associated to, a list layout.
...
<Composite name="composite">
<LayoutRef association="list" layout="training:EntitySearch" name="search" query="true"/>
<LayoutRef layout="training:EntityList" name="list"/>
</Composite>
...
base : identifier
Base class filter class that this filter is combined with
When a filter is applied to a list bound to a base class, all subclass definitions are pulled in as well.
When a filter is applied to a list that is bound to a subclass, all base class definitions are pulled in as well (but not sibling classes).
| Valid values based on“string”. | |
|---|---|
| :?[\p{L}_][\p{L}\p{N}_]*(:[\p{L}_][\p{L}\p{N}_]*)* |
Value must begin with a letter or an underscore. Case and length are not restricted. Letters, numbers and underscores are allowed. Colon is used as a scope separator. Spaces and other punctuation characters are not allowed. |
class : identifier
Domain class by which instances are filtered
| Valid values based on“string”. | |
|---|---|
| :?[\p{L}_][\p{L}\p{N}_]*(:[\p{L}_][\p{L}\p{N}_]*)* |
Value must begin with a letter or an underscore. Case and length are not restricted. Letters, numbers and underscores are allowed. Colon is used as a scope separator. Spaces and other punctuation characters are not allowed. |
text : string
Association path to an attibute to be used for text filtering
This is used for filtering from the text area of the filter control.