Difference between revisions of "Property Based Content Filters"

Latest revision as of 10:42, 27 June 2024

The UI can be customized to accept user inputs as filter criteria, and reduce the entire child list to a sub-list based on property values that contain that text. Each filter is 'attached' to a single metaproperty, and multiple filters can be applied at once.

When multiple filters are used at the same time, they are combined with "logic and".

For performance/usability reasons, the result list is not immediately refreshed as one types in the text box. Instead, it only happens after the ReloadChildListCommand is triggered.

However, note that these content-based filters:

• Require a custom Child Area template name to work. This customizing will not work applied to the UBIKChildArea.
• Work directly on the Children.Items collection. While filters are active, anything derived from this collection (such as Children.Items.Count or custom datasources like ListCollectionView / sfDataSourceExt) will also be affected.

Usage

For simple text input, it is enough to create a text input control with a TwoWay relationship to the Children.Filter[x]. However, the TwoWay binding doesn't always work well with more advanced implementations, such as selection. In such cases, the alternative is to use the UpdatePropertyFiltersCommand to supply the filter criteria. Both approaches are described below.

Text Input

This is shown as a single text box. The two way binding on Text allows the entered text (case insensitive) to be used as the filter value on property "SomePropertyName" (case sensitive).

Selection

Selection is trickier to achieve than direct input, as often a metaproperty's actual value might differ from the text that is displayed for that value. Just think of integer-based statuses, or GUID properties.

List Properties

The below examples use a custom ComboBox/Picker control to display a list of items. Because the filter comparison is based on the DisplayValue of the metaproperty, the DisplayText of the selected object is then passed on as a part of the command parameter and later used as a filter criterion to filter for objects that have the same the string.

Note that several elements are required for this customization to work:

• SelectedValuePath informs the control of which property should be supplied to the command as a filter criteria. This should match what is supplied in your KeyValueParameter.
• DisplayMemberPath/ItemDisplayBinding informs the control of which property should be visualized as the displaytext of your selection. Note that this is a binding on Xamarin only.
• In UWP: PlaceholderText binds to the same value as your SelectedValueExt to display the current selected item. This is a workaround for a failure of the ComboBox control to correctly display an active selection when the control is rendered. In Xamarin, a secondary label is required to display a placeholder text when the Picker's SelectedIndex is null.

Furthermore, this approach makes use of the Children.UpdatePropertyFiltersCommand, which uses the following parameters:

• ClearPropertyFilters: Clear out all existing filters at the current level before executing the command. This is optional and defaults to false;
• All other parameters: KeyValue pairs used as filter criteria where the Keys are the names of the metaproperties by which you want to filter.

ItemsSource

The ItemsSource in the above example is a way to populate the selection list dynamically by taking the MetaProperty.SelectiveList items of the STATUSCOLOR property that we are filtering, taken from the first child in the list. This selection list will therefore become empty if all items are filtered out of the Children collection.

For simple string properties, it is also possible to hardcode the options in the selection list as follows:

Note that you will then need to remove references to the DisplayText, as the x:String value becomes the value used to filter.

GUID Properties

The above controls:ComboBoxExt and controls:PickerExt examples can be converted to filter GUID values as follows:

Note that in this example, a Properties.AllItems[LK_PLANT_QUERY] is added to the Content object to provide the list of items displayed by the Picker, as a workaround to the Children.Items[0] approach.

Displaying Results

For performance/usability reasons, the result list is not immediately refreshed as one types in the text box. Instead, it only happens after the ReloadChildListCommand is triggered.

This can be done on a dedicated button:

Or in certain cases, can be combined with the filter input to trigger immediately:

Evaluation Criteria

By default, the expression used for filtering is Content["PROPERTY_NAME"].DisplayValue.ToLower().Contains(FILTER_VALUE.ToLower())==true. In other words, it checks whether the specified filter value (as string) is contained in the display value of the property.

In more advanced scenarios where a different type of comparison is needed, the example (or more specifically the one KeyValueParameter) can be extended into the following, e.g. comparing whether the specified filter value is equal to the value of the property.

""" and "\" are used for escaping the special characters in XAML and C# code respectively. "{0}" and "{1}" are placeholders and get replaced by the property name and the filter value. The end expression being executed in this example is Content["PROPERTY_NAME"].Value.ToString().Equals(FILTER_VALUE)==true

UI Customizing

Filtered Indicator

You can also customize UI elements to indicate that filters are active.

The above border is shown when a filter is active.

Other bindings exist on the Filters collection. Use Developer Mode to see what possibilities are available. Some examples are:

Troubleshooting

As previously mentioned, only areas with a custom Child Area template name can make use of filters. When Filters (or Sorting) are applied, a config file is created at Local State/Configs where the filter data is written and persisted.

Note that during a trial and error phase, filters may be applied that makes a child list fully/partially filtered out of view.

This file can be used to inspect how a xaml implementation is being translated into filter criteria.

Deleting the file (with the client closed) will remove forget any filters.