Feature Configurations ins an umbrella term for configurations of functionalities shown in table 1. All these configuration share a common way how they they can be configured for sets of features using a defined Feature/Feature type context (FFT Context). Validation Rules for features are one example of a feature configuration.

An FFT Context is used to define for which features a specific feature configuration is applicable.

An FFT Context can be an explicit or implicit. An explicit FFT Context directly defines the features the configuration applies to. An implicit FFT Context does not define the features it applies to directly but defines characteristics a feature must have so that a configuration applies.

By using implicit FFT Context you can therefore define configurations that will also automatically apply to new or modified features if their characteristics match the FFT Context.

When the Application Server searches for a setting for a specific feature it uses a specific context evaluation logic.

Example: The default value for a property in a property structure is defined within a property structure configuration that is applicable in a specific feature context. If that default value is defined with a feature context of Domain A and feature Type B the default value will be applicable for all features assigned to domain A and feature type B.

FFT Context types

Table 1 lists all types of FFT Contexts supported by the Application Server. Note that each context always implies a feature type i.e. regardless  of which context type is chosen the setting will always apply only to features of one specific feature type, i.e. feature settings are always feature type specific.

A feature setting with a context that includes a domain will match for all member features i.e. all features assigned to that domain or any of its sub domains.

Table 1: Feature setting contexts

FFT Context evaluation

Depending on the type of configuration that is associated with the FFT Context, the system uses two different approaches to determine the applicable configurations for a specific feature: the first match or all matches approach.

The first match approach is used whenever only one configuration is needed. E.g. the default value of a property in  a property structure can be only one value, there might be different configurations defining different default values with still only one of these settings can be used.

The first match in the first match approach is determined by sorting all settings with matching contexts by their feature setting context specificity. Table 2 lists the contexts from highest specificity to lowest specificity. The first match is the match with the highest specificity.

The all matches approach is used whenever all of the configurations that match the context of the feature can be used. E.g. there can be any number of validation rules for a property in a property structure. When validating a property all validation rules whose context match the current feature's context will be checked.

Table 1: Feature contexts ordered by their specificity, highest specificity first