CoreMedia offers some predefined validators for common usecases and an API to implement your own, based on project-specific content validation requirements. The table below gives an overview of predefined validators. For details and more validators, see the Shared / Middle API documentation (available at the CoreMedia download area), especially the packages com.coremedia.rest.validators and com.coremedia.rest.cap.validators.

The easiest way to declare a validator is to provide it as Spring Bean. For example, an ImageMapAreasValidator is declared like this:

@Bean
@ConditionalOnProperty(
  name = "validator.enabled.image-map-areas-validator.cm-image-map",
  matchIfMissing = true)
ImageMapAreasValidator cmImageMapAreasValidator(CapConnection cc) {
  ContentType type = cc.getContentRepository().getContentType("CMImageMap");
  return new ImageMapAreasValidator(type, true, "localSettings", "pictures.data");
}

The @ConditionalOnProperty annotation allows you to disable this validator by the setting the application property validator.enabled.image-map-areas-validator.cm-image-map=false. If you do not need this, you can omit it. By convention, such validator enabling properties start with the prefix validator.enabled, the third segment is the lowercase/hyphen variant of the validator class, and the last segment is a short description.

The ImageMapAreasValidator validates a content as a whole. However, most predefined validators are only property validators, which validate a single property value of a content. Property validators must be wrapped into a ContentTypeValidator. For example, a NotEmptyValidator, which ensures that the title property of a CMArticle content is not empty, is declared like this:

@Bean
@ConditionalOnProperty(
  name = "validator.enabled.content-type-validator.article-validation",
  matchIfMissing = true)
ContentTypeValidator articleValidator(CapConnection cc) {
  ContentType type = cc.getContentRepository().getContentType("CMArticle")
  return new ContentTypeValidator(
          type,
          true,  // validate also subtypes of CMArticle
          List.of(new NotEmptyValidator("title")));
}

Here, the content type validator is configured to apply to all subtypes of the given content type, too.

To provide multiple validators for a content type, you can declare multiple ContentTypeValidator beans or, more commonly, multiple property validators in a single content type validator. Note that you can only disable the whole content type validator. This may affect your decision how to arrange property validators in content type validators.

For all property validators that inherit from AbstractPropertyValidator (esp. all predefined property validators), you can set the field code to an issue code of your choice. If you choose not to do so, the class name of the validator implementation will be used as the issue code. For example, the validator com.coremedia.rest.validators.RegExpValidator creates issues with code RegExpValidator by default.

Alternatively, you can provide validator declarations as Json configuration files. The equivalent Json configuration for the above validators looks like this:

{
  "image-map-areas-validator": {
    "cm-image-map-areas": {
      "content-type": "CMImageMap",
      "subtypes": true,
      "struct-property": "localSettings",
      "image-property-path": "pictures.data"
    }
  },
  "content-type-validator": {
    "article-validation": {
      "content-type": "CMArticle",
      "subtypes": true,
      "property-validators": [
        {
          "not-empty-validator": {
            "property": "title"
          }
        }
      ]
    }
  }
}

The keys of the outer map, image-map-areas-validator and content-type-validator, denote validator factories. You find the factory ID in the API documentation of each validator. By convention, it is the lowercase/hyphen variant of the validator class (just like the third segment of the enabling properties).

The second level keys, cm-image-map-areas and article-validation, are validator IDs. You might encounter them in log messages, so you should use reasonable IDs that you can easily recognize. The validator maps contain the configuration data for the particular validator instance. The attributes content-type and subtypes are common for most validators. The other attributes depend on the particular validator class. Usually, it is the lowercase/hyphen variants of the fields that can be set by constructor arguments or setter methods of the validator.

The property-validators attribute of a content-type-validator is a list of maps, each of which denotes a property validator. Each map has exactly one entry, whose key (not-empty-validator in the example) is the factory ID of the property validator. The value is a configuration map for the property validator instance, which usually consists of the property to validate, the optional code field, and possibly additional fields like ranges or sizes to validate against.

Just like Spring bean validators, you can disable Json-declared validators by setting the application property validator.enabled.<factoryID>.<validatorID> to false.