A unique identifier for the specific implementation, like "RequireText" or "Range". Its value appears in the IssueFound.errorCode property unless overridden in ValidatorConfig.errorCode. It allows the consumer of both to correlate those instances with the specific condition. When defining conditions through a ConditionConfig, the conditionType property must be assigned with a valid ConditionType.
Helps identify the purpose of the Condition. Impacts:
Evaluate something against the rules defined in the implementation. Return whether the data was consistent or violates the rules, or the data couldn't be used to run the rule.
Most values are found amongst the ValueHosts in the ValueHostsManager. Conditions can look them up using ValueHostsManager.getValueHost().getValue() or getInputValue(). This parameter is used as an optimization, both to avoid that lookup and to avoid the user typing in a ValueHostName when creating the Condition instance. Validator.validate() knows to pass the ValueHostName that hosts the Validator. Expect this to be null in other cases, such as when Condition is a child of the AllMatchCondition and its peers. In otherwords, support both ways.
Its primary use is to lookup ValueHosts to get their data.
Any of these values:
Generated using TypeDoc v0.25.12
The basis for any condition that you want to work with these validators. There are a number of implementations based on its subclass IConditionCore, all which allow a Config approach of configuration. Implement this directly when you want to handle all of the work in the evaluate() function yourself, and supply your own way of configuring.
NOTE: Classes that implement ICondition can introduce IDisposable knowing the dispose function will be called as a Validator is disposed. Conditions that reference other conditions should call toDisposable(cond)?.dispose() in response.