public interface GridFiltering
search
criteria
can be applied to a grid
to filter
the data being displayed. Typically, there are two types of criteria that affect how a grid matches data:
grid
or its
dataSource
, and never made
available to usersexplicit criteria
are combined
and used to match records.
Note, however, that attempts to fetch with more restrictive criteria may not result in a
server-trip, because ResultSet
s implement local filtering
adaptively and may not require a server-trip if a filter can be achieved from local caches.
implicit criteria
, which
is never shown to the user, or initial criteria
, which may be
shown for editing in the grid's builtin filter-row
. You can also
provide both types, if only some parts of the criteria should be public. filter-row
that allows users to apply search-values on a per-field basis. When ListGrid.allowFilterOperators
is true, the default, users can modify the search operator
assigned to a given field via the grid's
header context-menu
,
allowing for more complex matching. If the selected operator is not the field's default operator
, or if
ListGrid.alwaysShowOperatorIcon
is true, the current operator is indicated in a small icon in
each filter-field. Developers can interact with a field's search operator with ListGrid.getFieldSearchOperator()
, ListGrid.setFieldSearchOperator()
and ListGrid.clearFieldSearchOperator()
.
Criteria in the filter-row reflects current public
criteria that can be
edited
. Developers can retrieve this criteria with ListGrid.getFilterEditorCriteria()
and set it with ListGrid.setFilterEditorCriteria()
. When the filter-row is showing, Calls to APIs such as
ListGrid.setCriteria()
or ListGrid.fetchData()
will apply criteria
to the filter-row, if the editors there allow it. Any criteria applied by these methods, that
cannot be edited by the associated field's filter-editor, are still applied to fetches and
will be returned by calls to ListGrid.getCriteria()
or ListGrid.getFilterEditorCriteria()
, but are not shown to the user for editing.
Developers
may specify a field's filterEditor-type
, and this can be a custom FormItem
class that uses getCriterion()
, setCriterion()
and canEditCriterion()
to manage
the criteria it works with.
For more complicated cases or more control, developers can
implement ListGrid.filterEditorSubmit()
.
Criteria from the filter-row is combined with other sources of criteria when data is fetched.
form
outside of the grid, that produces
criteria, you can apply the criteria by passing it to fetchData
or filterData
. The primary difference
between these two APIs is that filterData
applies a DSRequest.textMatchStyle
of
substring, so that records are matched by case-insensitive substring comparison. If
you have the FilterEditor
showing, these external criteria will be appear in the
filterEditor, where supported. Developers can apply additional external criteria without that
effect by passing them to DataBoundComponent.setImplicitCriteria()
, or by setting ListGrid.searchForm
to the external
criteria form.
If you need more power or variance than the filter-row provides, you can
set ListGrid.allowFilterWindow
to show a full-blown FilterBuilder
, to construct more complex criteria that can
also include logical operators like or.
All sources of criteria are combined to match records when data is fetched.
view-state
and
via the SavedSearches
feature, which is turned on by default.