Validation on Fields - lblod/ember-submission-form-fields GitHub Wiki

For each field within this addon, you have the flexibility to implement various types of validations, ranging from simple "required" constraints to more specific value-based validations. Below, you can find a list of available validations and instructions on how to incorporate them into your fields.

Validation types

• RequiredConstraint
• MaxLength
• Codelist
• ExactValueConstraint
• UriConstraint
• ValidDate
• ValidDateTime
• ValidInteger
• PositiveNumber
• ConceptSchemeConstraint
• ValidYear
• ValidEmail
• ValidIBAN
• ValidPhoneNumber
• DateInPast

Adding a validation

Validations on a field are put under the predicate form:validations and followed by a blankNode or by a specific node. A blankNode is an object that is not defined by an id or name.

BlankNode: A blankNode is created with the [] in there you define the type of the validation you are adding with it's necessary values.

ext:myField ;
    form:validations 
        [
            a form:PositiveNumber;
            form:grouping form:MatchEvery;
            sh:path ext:numericalInputValue;
            sh:order 1;
            sh:resultMessage "Needs to be positive"
        ] ;

Specific node: When you create a validation object for example nodes:myPositiveNumberValidationNode you can just add that as value of the predicate form:validations

nodes:myPositiveNumberValidationNode a form:PositiveNumber;
    form:grouping form:MatchEvery ;
    sh:path ext:numericalInputValue ;
    sh:order 1 ;
    sh:resultMessage "Needs to be positive"

ext:myField ;
    form:validations nodes:myPositiveNumberValidationNode ;

Path

This one is very important to ensure that the validation targets the correct data in your application, it's essential that the path on the field corresponds to the path on the validation node. Alignment between these paths is crucial for the validation process to accurately target the desired data and ensure that the validation rules are applied to the correct field.

ext:numericalInputField a form:Field ;
    ...
    sh:path ext:numericalInputValue; <= path on field
    form:validations 
        [
            a form:PositiveNumber;
            ...
            sh:path ext:numericalInputValue; <= path on validation
        ] ;

Validation severity

Validations that fail are considered errors by default. Sometimes you simply want to draw attention to a certain field if the provided value is strange, but not wrong. For those cases it is possible to configure the validation to be a warning instead. You can do this by adding the sh:severity predicate with the sh:Warning value.

ext:someDateField a form:Field ;
    ...
    sh:path ext:someDate; <= path on field
    form:validations 
        [
            a form:DateInPast;
            ...
            sh:path ext:someDate;
            sh:severity sh:Warning;
        ] ;

When a field fails on a warning validation it will look different compared to the fields with errors. Validating the form will also ignore any warning validations, so forms can still be submitted even if there are warnings visible.

Examples

Examples sometimes make it easier to understand how it works. That's why I created a PR that has a starting point to show all the validations that are possible on fields. As long as this is not merged you can just find examples there under Basic form fields with validations

Positive number

ext:numericalInputField a form:Field ;
    sh:name "Numerical input" ;
    sh:order 221 ;
    sh:path ext:numericalInputValue;
    form:displayType displayTypes:numericalInput ;
    form:validations 
        [
            a form:PositiveNumber;
            form:grouping form:MatchEvery;
            sh:path ext:numericalInputValue;
            sh:order 1;
            sh:resultMessage "Needs to be positive"
        ] ;
    sh:group ext:mainPg .