Flow Steps and Rule Steps (Advanced) Custom Validation
  • Updated on 09 Dec 2013
  • 2 minutes to read
  • Print
  • Dark
    Light

Flow Steps and Rule Steps (Advanced) Custom Validation

  • Print
  • Dark
    Light

Overview

Using the techniques described below, you can cause validation messages to appear on the properties and inputs of your steps at design time. These validations can evaluate only the value of a given property (e.g., show validation error if property X is empty) or they can be dependent on values in other properties (e.g., show validation error if property X is true AND property Y empty). Decisions has some built-in validation attributes that can be assigned to properties to check simple conditions like value of a number or emptiness of a string. For more complex validation checks (and for validation checks of inputs as opposed to properties), you will need to use custom validation methods. Both of these are described below.

Example

Examples of Simple Property Validation
On your class, inherit and implementINotifyPropertyChanged . This will allow the validation messages to clear when the property value has changed to a valid value.

Decorate your class with theValidationRules attribute. This attribute alerts the Decisions framework that there are validation rules on this object.

Decorate the property you want validation on with one of the following attributes:
EmptyStringRule - Shows validation issue if property string value is empty (this check counts white space as empty).
NullRule - Shows validation issue if property is null.
NumberAboveRule - Shows validation issue if property value is below a given number. Must be given at least one argument to define the minimum numeric value that this property is allowed to have.
NumberBelowRule - Shows validation issue if property value is above a given number. Must be given at least one argument to define the maximum numeric value that this property is allowed to have.

Each of these properties can be overridden to provide a custom error message and to change the break level. The break level can be specified as either Warning or Fatal . If no break level override is supplied the Fatal level is used by default. Warning break level causes a Yellow warning message and exclamation point icon to be shown while a Fatal break level causes a red message and exclamation point to be shown. Below is a screen shot showing how the Fatal and Warning level validations display in the designer.
2017-02-15_143434.png

Sample Code for using each of these attributes:

 [EmptyStringRule]
public string Name
{
    get { return name; }
    set
    {
        name = value;
        this.OnPropertyChanged("Name");
    }
}

[NullRule(BreakLevel.Warning)]
[DataPairTypeListEditorAttribute]
public DecisionsType Type
{
    get { return type; }
    set
    {
        type = value;
        this.OnPropertyChanged("Type");
    }
}

[NumberBelowRule(5)]
public int SmallNumber
{
    get { return smallNumber; }
    set
    {
        smallNumber = value;
        this.OnPropertyChanged("SmallNumber");
    }
}

[NumberAboveRule(5, "Number must be above 5")]
public int LargeNumber
{
    get { return largeNumber; }
    set
    {
        largeNumber = value;
        this.OnPropertyChanged("LargeNumber");
    }
}

Examples of Custom (method based) Validation

The following describes how to do more complex validations using custom methods.

On your class, inherit from and implement  IValidationSource .

Within this method you can write code that evaluates any kinds of conditions you want to. Below is an example showing how this method would be written to evaluate the value of a date field based on the value of a Boolean field. ```
public ValidationIssue[] GetValidationIssues()
{
    List issues = new List();

if (ForceFutureDate && MyDate < DateTime.Now)
    {
        issues.Add(new ValidationIssue(this, "Date must be future", string.Empty, BreakLevel.Fatal, "MyDate"));
    }

return issues.ToArray();
}


Was this article helpful?