Content Validation × Mattrbld

Almost every field that holds content in Mattrbld can have one or more validation rules attached to it. In this article you’ll learn what these rules are and how to apply them so you can ensure that the data of content you edit in Mattrbld always adheres to the rules you require.

Like everything else in Mattrbld, content is validated on the client side. This means you cannot fully trust that the content in your central repository will always be valid, since a malicious user could tamper with the validation code (or, much more easily, simply clone the repo to their local machine and make the changes in a text editor).

This feature is intended to minimise potential mistakes and to aid Content Editors, not as a security measure.

Validation Options

The validation property of fields is an object with the following properties:

{
  …
  "validation": {
    "enforceMinMax": Boolean,
    "max": Number,
    "min": Number,
    "regex": String,
    "regexError": String,
    "required": Boolean,
    "unit": String,
    "isString": Boolean
  }
  …
}

Not all fields may have all properties (see the Field Reference for more information), but all fields with validation options have at least one of them.

enforceMinMax controls whether or not the values of min and max are enforced, i.e. cause an error instead of just a warning. This is useful when Content Editors should stick to a given length / amount, but may go over or under in special circumstances if they really need to.
min and max denote the minimum / maximum value a field can have. What exactly this number is referring to differs for each field, i.e. in a text field it is the length of the string, while in a number field it’s referring to the number itself and in a columns field it refers to the number of columns, etc.
regex is a JavaScript regular expression in string form that the content must match to be valid. It can either be just the regular expression itself e.g. ^[A-Z0-9]+$, or a regular expression with modifiers like /^[A-Z0-9]+$/gi.
regexError is the error message displayed if the content doesn’t match the regular expression. Use this to give Content Editors a useful hint of what rules they have to stick to, i.e. in the example above: ‘A string of characters consisting only of uppercase letters and numbers’.
required signals that the field may not have a value of null i.e. be left empty. Fields that must match a regular expression which does not allow for empty strings, or with a min value are always required. Required fields will also be marked as such in the Schema Editor.
unit and isString are used internally to generate appropriate labels for the input fields and determine how to validate the field. Especially in the case of isString it’s for the best to stick with the default.

Adding a Validation Rule to a Field

In order to add a validation rule to a field, you can click the field in the Schema Editor to show its options and scroll to the “Validation” section. Here you’ll find all the appropriate input and toggles in order to set the rules for that field.

If you find yourself using similar or equal validation rules in multiple places of the same Schema, or even multiple Schemas, consider saving that field as a Custom Field to make it reusable.

Validation rules are a powerful feature that allows you to specify the shape of your data in even more detail than a Schema without validation rules already does. Whether you need a specific format for ids in your application, or just want to keep Content Editors from writing novels in a single text field by setting a maximum length, once again your imagination is the limit here.

Now that you have learned what Schemas are and how to create and validate them, it’s time get to know just how versatile the fields are that you use in your Schemas.

Validation Options

Adding a Validation Rule to a Field

Take full control over your content.