Take the community feedback survey now.

Ben  McKernan
Feb 4, 2015
  12108
(0 votes)

The new and improved allowed types

TL;DR
The latest pre-release version of the EPiServer.CMS.UI package contains the new and improved allowed types attribute. If you are feeling adventurous then upgrade and try it out. The improvements are:

  • Clicking the "create a new block" link of a content area will now filter the block types that appear based on allowed types.
  • It is now possible to restrict a subset of the allowed types.
  • Interface types are now supported.
  • UI descriptors are now automatically generated for content types classes and their base classes.
  • Validation occurs for allowed types in the content area.

AllowedTypesAttribute

Most of you have probably read previous blog posts from myself and others on the allowed types attribute and its usages and its limitations. For those who don't know what it is, it is an attribute that can be applied to properties on your content type model in order to control what content types that property can accept. For example, only allowing images on a gallery property. The code looks like this:

[AllowedTypes(new []{ typeof(ImageData) })]
public virtual ContentArea Gallery { get; set; }

In the next major version of EPiServer (EPiServer.CMS.UI 8.0.0) we have made a lot of improvements to the allowed types in order to support requested features and fix problems in the current version. The next version is currently available in the nuget feed as a pre-release package if you are interested to give it a test run.

Creating Content from the Content Area

The biggest problem with the current implementation of the allowed types, and also the most up-voted bug on EPiServer World (110190), is the fact that allowed types doesn't filter the list of content types when creating a block from a content area; it only affected drag and drop. This has now been fixed meaning that it is no longer possible to add disallowed types to the content area either via drag and drop or the create link.

Validation of Allowed Types

The content area has also been modified in the core so that, when saving or publishing, it validates whether it contains any types that are not allowed. This ensures that changes to a content area via code also follow the allowed types restrictions.

Restricted Types

An additional feature we have added to the allowed types attribute is the ability to specify a subset of types that should not be allowed. For example, it is quite common to have a content area which should accept all blocks except for blocks which don't fit; i.e. the jumbotron block in the alloy templates is too big to be rendered in the sidebar. The restricted types are passed through as the second constructor argument on the allowed types attribute. The code looks like this:

[AllowedTypes(new[] { typeof(BlockData) }, new[] { typeof(JumbotronBlock) })]
public virtual ContentArea RelatedContentArea { get; set; }

Automatic Generation of UI Descriptors

Currently the system automatically creates UI descriptors for all the registered content types. This means that you can specify a particular content type as an allowed or restricted type without the need to create the UI descriptor yourself. However this was not the case for base classes and thus you needed to create a UI descriptor for any base classes you wanted to specify in the allowed types. In the next version we have refactored the automatic generation so that base classes are also generated, meaning that you can specify any class type without needing to create a UI descriptor yourself.

If you have a type that you want to create a UI descriptor for in order to, for example, have a custom icon. Then you can still create the UI descriptor and it will take precedence over the automatically generated one.

Interface Support

We have also made changes to support UI descriptors for interfaces, meaning that it is possible to specify an interface type as the allowed type. For example, if you had an interface for blocks that should appear in the sidebar then the code would look like this:

[AllowedTypes(new[] { typeof(ISidebarBlock) })]
public virtual ContentArea RelatedContentArea { get; set; }

However, unlike the content type classes and their base classes, UI descriptors are not automatically generated. So in order for the above to work you will need to create a UI descriptor. 

Feb 04, 2015

Comments

Please login to comment.
Latest blogs
A day in the life of an Optimizely OMVP - Opticon London 2025

This installment of a day in the life of an Optimizely OMVP gives an in-depth coverage of my trip down to London to attend Opticon London 2025 held...

Graham Carr | Oct 2, 2025

Optimizely Web Experimentation Using Real-Time Segments: A Step-by-Step Guide

  Introduction Personalization has become de facto standard for any digital channel to improve the user's engagement KPI’s.  Personalization uses...

Ratish | Oct 1, 2025 |

Trigger DXP Warmup Locally to Catch Bugs & Performance Issues Early

Here’s our documentation on warmup in DXP : 🔗 https://docs.developers.optimizely.com/digital-experience-platform/docs/warming-up-sites What I didn...

dada | Sep 29, 2025

Creating Opal Tools for Stott Robots Handler

This summer, the Netcel Development team and I took part in Optimizely’s Opal Hackathon. The challenge from Optimizely was to extend Opal’s abiliti...

Mark Stott | Sep 28, 2025

Integrating Commerce Search v3 (Vertex AI) with Optimizely Configured Commerce

Introduction This blog provides a technical guide for integrating Commerce Search v3, which leverages Google Cloud's Vertex AI Search, into an...

Vaibhav | Sep 27, 2025

A day in the life of an Optimizely MVP - Opti Graph Extensions add-on v1.0.0 released

I am pleased to announce that the official v1.0.0 of the Opti Graph Extensions add-on has now been released and is generally available. Refer to my...

Graham Carr | Sep 25, 2025