Now Available: Episerver Property Validation

I'm trying to do more to get code wrapped up into packages and put into the Episerver Nuget feed.

The first of these I've managed to get posted is a collection of validation attributes that can be applied to different types of content properties. Some of them affect strings, some affect media, and some affect lists/arrays, including ContentAreas.

I won't go into full detail for each here. For that, see the ReadMe on Github. What I will do is pick one or two and go through why I thought these were important to share and use.

Episerver is one of the most author-friendly CMS platforms on the market - at least that I've seen. Though many of its competitors offer similar functionality (in-context editing, drag and drop), Episerver's solution is one of the smoothest and stands out as a differentiator. However, the platform can only do so much when the content schemas, property configurations, and enhancements to that experience are the responsibility of another team - and rightly so.

To that end, there are two phrases I find myself repeating often:

1. Authors are the "forgotten consumer" of the final application.
2. If the authors can't use the application, then the project is doomed to fail.

While I could rant for a while on the author experience, where I've seen successes or failures, and how I think it could or should be addressed, I won't do that here and now. I'm merely setting the stage.

What I want to achieve with this post and with the associated Episerver add-on is provide implementors with something that can help make both the authoring and end-user experiences more consistent, more helpful, and a little bit easier. Though it isn't exactly flashy.

In order to explain how this helps, I'm going to nit-pick one thing about Episerver (not their fault) and note upon a community post that helped fuel this package.

There's Required and then there's Required.

Episerver works well with .NET's own validators, as they should and I think we can all appreciate it. We developers often use the [Required] attribute for any number of fields. However, there are two circumstances under which we do so:

1. The rendering for this model won't function without this value. E.g., generating a news list and needing to know the source for that content.
2. The content should not be published without this value. E.g., the author needs to make sure the byline is entered for every press release.

I argue that these are two distinct use-cases and the [Required] decorator should only be used for the first.

Using [Required] on a property means that .NET will throw a ValidationException if the field is empty. Episerver therefore interrupts the authoring flow in order to capture these values and then proceeds into the in-page editor. If there is a functional requirement, then this is great. But it's more of a pain if it's merely due to fields being required for publication.

So the package includes a new attribute to address the second scenario: [RequiredForPublish]. Used the same as [Required], this attribute will allow the in-page editor to load immediately and will provide helpful error messages (which I'll move into translation soon) to the author if a property is left empty.

Count of Type

Another set of validators actually came from a question in the community, as inspiration often does.

You can visit the link and see the question in full, but in effect the user wanted to validate items in a ContentArea by type. I think a good example for this would be to restrict a home or landing page so that they could only contain a single carousel or banner and also must contain four teasers. I really like this idea as I think anyone who's managed a site and experienced authors "going rogue" should. (No, you cannot have a cloud background and your own messy JavaScript...)

So I thought it would be a fun experiment to include validators for Exact/Minimum/MaximumOfType. That way you can specify some level of restrictions on the makeup of a content area not just by restricting which types are allowed, as Episerver provides, but how many of each type.

Note, however, that this may interfere with personalization against the blocks and should therefore be used sparingly. I may look into accommodating personalization groups for these validators.

For full details, check out the ReadMe and code on Github. The nuget package is now available for use via Episerver's nuget feed.

Happy coding.