Validations

Validations are implemented as validation groups which allows us to organize, defined them as a set of simple validation rules. On one page can be defined more than one validation group and each group can perform validation independently from other validation groups on the page.

Validation group we create as a simple class which need to inherit AbstractValidator class. Aslso that class need to implement interface, in order to leave the possibility of replacing that class during implementation phase, according to needs. In validation class we just need to defined set of validation rules which will be executed. For every validation rule we defined property which will be validate, validation (also class which can be override during implementation), message (can be just message or translation key) and scope of validation (scope can be single property or hole class). Also, for every role can be defined order (default order is in accordance with the order in which the rules are added).

public class StandardPaymentBasicValidate : 
         AbstractValidator<StandardPaymentTransferObject>, IStandardPaymentBasicValidate
{
    public StandardPaymentBasicValidate()
    {
        AddValidationRule("CreditorReferenceModel",
            ApplicationBase.Current.ResolveService<IIsNotNullOrEmptyStringValidator(),
            "payment_field_model_is_madatory");

        var isInAccordanceWithRegexPatternValidator = 
 ApplicationBase.Current.ResolveService<IIsInAccordanceWithRegexPatternValidator>();
            isInAccordanceWithRegexPatternValidator.CheckIfInputNullOrEmpty = true;
            isInAccordanceWithRegexPatternValidator.RegexPattern = ApplicationBase.Current.Config.FactoryConfig_Regex_Pattern_NoSpecialCharacters;

            AddValidationRule("CreditorReferenceModel", 
                isInAccordanceWithRegexPatternValidator, "Just message, no translation");
     }
}

public interface IStandardPaymentBasicValidate :  
    IAbstractValidator<StandardPaymentTransferObject>
{

}

As already wrote, during implementation, StandardPaymentBasicValidate class can be replaced with another with different set of rules (or even without rules).

Usage of defined validation class, for example on page

public DataValidationObject<StandardPaymentTransferObject> ValidationData
{
    get => GetValue<DataValidationObject<StandardPaymentTransferObject>>();
    protected set => SetValue(value); 
}

protected override async Task NextPage()
{
    IStandardPaymentBasicValidate val = 
        App.ResolveService<IStandardPaymentBasicValidate>();

    ValidationData = val.Validate(PaymentData);

    if (ValidationData.IsValid == false)
    {
        // display messages
    }
}

Validation message will display on UI bellow the entry.

Showing validation message as a popup, in this moment, is not implemented.

Implemented property rules are:

Validation Rule	Description
IsEarlierOrEqualThanDefinedDateValidator
IsEarlierThanDefinedDateValidator
IsGreaterOrEqualThanDefinedValueValidator
IsGreaterThanDefinedValueValidator
IsInAccordanceWithRegexPatternValidator
IsLaterOrEqualThanDefinedDateValidator
IsLaterThanDefinedDateValidator
IsNotNullOrEmptyStringValidator
IsNotNullValidator
IsReferenceModelSupported
IsSmallerOrEqualThanDefinedValueValidator
IsSmallerThanDefinedValueValidator
IsStringLengthCorrespondingToDefinedBoundaries.

Over time, this list will expand, according to needs. Every of listed validation can be override during implementation.

One interesting validation rule is IsInAccordanceWithRegexPatternValidator. This rule checks is the property value is in accordance with forwarded pattern. It’s important to mention that patterns can be defined as configuration parameter. It’s not very important for email pattern, but it’s important for pattern which will represent account format (just changing the configuration parameter we can adjust validation of account format).