Skip to main content
Jump to: navigation, search

Riena/UI filters

< Riena
Revision as of 09:31, 22 December 2008 by (Talk | contribs) (Validator Rules)

UI Filters


With the help of the UI filters some restrictions can be added to certain UI elements of a Riena application. E.g. add a validator to a text field or hide a sub module in the navigation.

UI Filters exits of a collection of rules. Is a filter added its rules are applied for the corresponding UI elements. A UI element can be a menu item, a node of the navigation or a ridget.
The UI Filters can be composed by adding any kid of rule. The UI filters themselves are added to any node of the navigation. The rules of a filter are only exploited for the node with this filter and all the child nodes.
At every time filters can be added to and removed from the navigation model. The changes which are results are immediately visible at the GUI.
So the UI filter can be used in a very flexible way and they are also very dynamically.

UI Filter

An UI filter itself only consists of a collection of rules and an identifier.

public interface IUIFilter {
	Collection<? extends IUIFilterRule> getFilterRules();
	String getFilterID();

UI filters can be added to any navigation node. They also can be removed. All nodes of the navigation (INavigationNode) are implemented the following interface:

public interface IUIFilterable {
	void addFilter(IUIFilter filter);
	void removeFilter(IUIFilter filter);
	void removeFilter(String filterID);
	void removeAllFilters();
	Collection<? extends IUIFilter> getFilters();

The implementation updates the GUI after adding or removing an UI filter.


How the UI elements will be manipulated is defined by the rules of the UI-Filters.
Therefore two scenarios exist.

A UI Filter is added.
The rule checks for every UI elements, if it is responsible for this element (matches).
Is this the case the rule is applied.

A UI Filter is removed.
Also the rule checks for every UI elements, if it is responsible for this element (matches).
Is this the case the changes which are caused by this rule are removed.

public interface IUIFilterRule {
	boolean matches(Object... args);
	void apply(Object object);
	void remove(Object object);

The rules can be divided in several categories.

  1. What are the changes of the rules? Is a Marker added (IUIFilterRuleMarker) or a validator (IUIFilterRuleValidator)?
  2. Is the rule responsible for a navigation node or a ridget?

Rules for navigation nodes

For navigation nodes only two different rules for adding markers exists. One rule adds a DisabeldMarker (viz. the node is disabled) the other one adds a HiddenMarker (viz. the node is not visible).

The constructor of both rules (UIFilterRuleNavigationDisabledMarker and UIFilterRuleNavigationHiddenMarker) takes a pattern that is used to identify the navigation nodes. This simple pattern may contain '*' for 0 and many characters and '?' for exactly one character.


A rule is applied if the ID of the navigation node matches the pattern of the rule. Not only is the ID of one navigation node used for the match, also the IDs of the parent nodes. All these IDs together are called longID or complete ID. Example:

Tree structure of a navigation model:

RienaApplication                 (ID=application)
    NavigationSubApplication     (ID=subApp1)
        ModuleGroup              (ID=uiprocessGroup)
            UIProcess            (ID=uiprocess)
                Demo1            (ID=demo01)

The complete ID of the sub module “Demo1” is:
The single IDs of the nodes are separated by a slash.
Because the rules can have pattern with wildcards, the following patterns matches:

  • /application/subApp?/uiprocessGroup/uiProcess/demo??
  • *demo01
  • */subApp1/uiprocessGroup/uiProcess/demo0*


The rule UIFilterRuleNavigationDisabledMarker adds a DisabledMarker to the navigation node, if the pattern of the rule matches the ID of the node (longID). The node is still visible but it cannot be selected.


The rule UIFilterRuleNavigationHiddenMarker adds a HiddenMarker to the navigation node, if the pattern of the rule matches the ID of the node (longID). The node is not displayed.

Rules for Ridgets

For ridgets two different kinds of rules exist. There are rules for adding markers and rules for adding validators.

Like creating rules for navigation nodes the constructor takes a pattern (ridgetIdPattern), that‘s used to identify the ridgets. The method matches decides, if the rule is applied.


Also the rules for ridgets are only applied, if the pattern of the rule matches the id of the ridget.
And also like the rules for the navigation nodes the method matches compares the pattern with the complete ID of the ridget. The complete ID is composed of the IDs of the navigations nodes and the ID of the ridget. A ridget with the ID “lastname” is part of the sub module “Demo1”. The complete ID:

Marker Rules

The following four rules add a marker, if the pattern of the rule matches the ID of the ridget:

This rule adds a DisabledMarker. The ridget is visible, but no value is displayed.

This rule adds a HiddenMarker. The ridget is not displayed.

This rule adds a MandatoryMarker. The ridget is marked as long not value is entered.

This rule adds a OutputMarker. The ridget is visible and also the value is displayed, but the value cannot be edited.

Validator Rules

Only one rule exists for validators. Validators (IValidator) can be added to a ridgets and validate the value. Is the value invalid an error marker is displayed.
To construct this rule (UIFilterRuleRidgetValidator) the pattern for the ID, the validator and the time of validation are necessary.
The validator must implement the interface IValidator. Riena provides a set of validtors: e.g. MinLength, MaxLength, ValidEmailAddress
For adding a validator to a ridget a point in time for validation is necessary:

The value is validated after every change.

The value is validated before writing the value into the model.

Back to the top