Eval Criteria # 9
Can custom validation rules be built?
A CMS is framework for future content. It doesn’t know what your content looks like in advance, which is why most systems allow the creation of custom content types.
In addition to baseline structure, a system can only make assumptions about how your content should be logically validated. So built-in validation rules have to make guesses and provide as much coverage for whatever situations might come up. There are a lot of patterns in content management, so things like whether a value is required or whether it falls within a range can cover a lot of use cases.
But what if you have something special? Occasionally, you need to validate an attribute value based on something completely specific to your organization or situation. This could be something that no CMS could predict in advance or be expected to support, or it might require access to others systems, specific to your organization.
In these situations, some systems can be configured with custom validation rules.
One of the prior examples when discussing pattern validation was a product number in a specific format. This can be validated by generic pattern matching, but the system doesn’t “understand” what it is – it doesn’t know that this is a product or anything about it. All that rule did was verify a string of characters conformed to a specified pattern. You have no idea if the entered value actually corresponds to a product available in your catalog.
What if you wanted to make absolutely sure your editors entered the product number of a valid product, meaning one not discontinued or out-of-stock? This means when the editor attempts to save the attribute value, the CMS needs to connect to the product catalog and perform a lookup on the product number.
Unless your product catalog is stored inside the CMS, or unless the CMS has some installed integration to your system (which would then, by definition, have to be a known, commodity catalog software), no CMS is going to do this out-of-the-box.
Server vs. Client Validation
As mentioned above, custom validation almost always involves writing executable code in whatever language the CMS is built on (PHP, C#, Java, etc.). More rarely, custom validation might execute client-side (in the browser; so, JavaScript) but this is less common since custom validation often involves contacting some other system to validate the attribute value, and you usually wouldn’t do that directly from the browser.
Some systems will allow you to provide both server-side or client-side validation, but more commonly, client-side validation simply performs a HTTP callback to the server, where the validation actually executes.
Client-side validation also presents another issue, as validation shouldn’t be the sole responsibility of the user interface. Content needs to be validated whenever a change is attempted, through whatever method. If we use the API of our CMS to bulk import a bunch of content, we want those validation rules to execute prior to storing the content in the repository – the API should reject content that doesn’t pass validation. Bypassing the user interface should not also bypass our validation rules.
Custom Validation Needs
The need for custom validation is inversely proportional to the depth of built-in validation rules. The more coverage provided by built-in rules, the less need you’ll have for custom validation.
Here are some situations where custom validation might take the place of built-in validation not provided by the system:
- Range validation, often in the forms of minimum or maximum lengths
- Text pattern validation that can’t be captured with regular expressions, such as the parsing of HTML or other text constructs
- Non-required format validation, where a specific format is required only if a value is entered
- Logical values unable to be coerced by the interface or otherwise captured by patterns. (For instance, an editor may only select weekdays in a date picker, however there is no way to eliminate weekends as a selectable option in the editorial element.)
- Dependent validation, where the execution of a rule or a logical variable of a rule is dependent on another value in the same set of changes. (For instance, an editor can’t specify Open in a New Window unless they have checked .)
Custom validation is helpful to preserve the resiliency of your content. It’s a more advanced feature that depends on some foresight by the CMS developers, and some foundational programming hooks in the system’s API.
Sometimes, however, custom validation isn’t enough. Instead we want to completely rewrite the attribute’s editorial interface and how it stores data. For this step, we need fully custom attributes.
Evaluation Questions
- Can custom validation rules be built?
- How are they enabled – through deployed code or configuration? If through code, do they have complete access to the API and native functions and constructs of the underlying programming language?
- Are they server-side, client-side, or both?