Interface ConditionConfig

Just the data that is used to identify the Condition class to use, along with its configuration -- usually fields also found in business rules. Each use of IConditionCore has its own inherited version of ConditionConfig to supply its own rules. Condition classes that implement IConditionCore are always passed the ConditionConfig as the one and only parameter. The ConditionFactory expects that. Once supplied to the Condition class, consider the ConditionConfig immutable.

ConditionConfig should not contain any supporting functions or services.

The server side could in fact supply this object via JSON, allowing the server's Model to dictate this. However, there are sometimes cases a business rule is client side only (parser error converting "abc" to number) and times when a business rule is server side only (looking for injection attacks for the purpose of logging and blocking.) Examples:

RequireTextCondition implements IConditionCore which usually looks like: { conditionType: 'RequireText' }

RangeCondition implements IConditionCore which usually looks like:
{ conditionType: 'Range', minimum: any, maximum: any }

interface ConditionConfig {
    conditionType: string;
    category?: ConditionCategory;
}

Hierarchy (view full)

Properties

conditionType: string

Identifies the class for ConditionFactory to create. It is also used as the Validator's errorCode when ValidatorConfig.errorCode was not assigned.

Most Condition classes have an official value for Category. This allows you to override that official value in special situations and supply a value when the Condition does not.

Generated using TypeDoc v0.25.12