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.