World is now on Opti ID! Learn more

Linus Ekström
Dec 13, 2013
  12760
(0 votes)

Customizing the look and behavior in the UI for your content types

In EPiServer 7.5 we have done some additions that makes it possible to alter quite a few things regarding how your content types should look and behave in the EPiServer UI. This is done by adding something called a UI Descriptor which is responsible for instructing the EPiServer UI how you want instances of the given content type to behave. Lets start with a simple example taken from the Alloy sample project:

using EPiServer.Shell;
using EPiServer.Templates.Alloy.Models.Pages;
 
namespace EPiServer.Templates.Alloy.Business.UIDescriptors
{
    [UIDescriptorRegistration]
    public class ContainerPageUIDescriptor : UIDescriptor<ContainerPage>
    {
        public ContainerPageUIDescriptor()
            : base(ContentTypeCssClassNames.Container)
        {
            DefaultView = CmsViewNames.AllPropertiesView;
        }
    }
}

What the code above does is configuring the following settings for the type ContainerPage:

  • A custom css class used as an icon (this is used for the navigation tree as well as different listings, for instance recent items).
  • Defines that the default view for items of this type should be the “All properties” view.

In the example above we are using one of the built in css classes in EPiServer but there is nothing preventing you from adding your own classes/icons (see Stefan Torstenssons blog post about how to add custom styles to the EPiServer UI http://world.episerver.com/Blogs/Stefan-Torstensson/Dates/2012/12/Adding-a-new-device-to-the-view-resolution-drop-down/).

ContainerPageScreenShot

Image showing how container pages have a different icon compared to other pages.

Hint: You can use the technique above if you want to have the “All properties” view as the default view for some of your content types, for instance a content type where it makes no sense using on page editing.

Content blocks in Tiny MCE

Another thing you can configure is the desired behavior when you drag-and-drop an item to a html editor. The default behavior for pages is that a link to the page is inserted to the editor. For blocks however, a “content block” is created using the same technology as for content areas. The following screen shot shows how a block is inserted to a html editor:

DndBlock

 

When the property is rendered to the page it will render using a partial renderer, following the same rules as for a content area:

Rendered block

 

We can change the desired behavior for what happens when dropping an item to an editor by setting the EditorDropBehavior property in the UIDescriptor. Lets try adding a ui descriptor to the SitePageData base class that all pages in the Alloy template inherits from:

using EPiServer.Shell;
using EPiServer.Templates.Alloy.Models.Pages;
 
namespace EPiServer.Templates.Alloy.UIExtensions
{
    [UIDescriptorRegistration]
    public class SitePageUIDescriptor : UIDescriptor<SitePageData>, IEditorDropBehavior
    {
        public SitePageUIDescriptor()
        {
            EditorDropBehaviour = EditorDropBehavior.CreateContentBlock;
        }
 
        public EditorDropBehavior EditorDropBehaviour { get; set; }
    }
}

 

Now when a page is drag-and-dropped to the editor, a content block containing the page is created instead:

DndContainerPage

And this is rendered using a partial template, just as for the block:

RenderedBlockAndPage

The settings for content types are inherited so settings you define will affect all inhirited types unless there is a more specific setting defined for a sub type. We currently have no good way to alter the setting for built in EPiServer types (PageData, BlockData etc.) so if you want to change settings for all types for a given main type (all pages, all blocks etc.) I recomend using a base class in your template package as in the Alloy example.

Dec 13, 2013

Comments

Please login to comment.
Latest blogs
Make Global Assets Site- and Language-Aware at Indexing Time

I had a support case the other day with a question around search on global assets on a multisite. This is the result of that investigation. This co...

dada | Jun 26, 2025

The remote server returned an error: (400) Bad Request – when configuring Azure Storage for an older Optimizely CMS site

How to fix a strange issue that occurred when I moved editor-uploaded files for some old Optimizely CMS 11 solutions to Azure Storage.

Tomas Hensrud Gulla | Jun 26, 2025 |

Enable Opal AI for your Optimizely products

Learn how to enable Opal AI, and meet your infinite workforce.

Tomas Hensrud Gulla | Jun 25, 2025 |

Deploying to Optimizely Frontend Hosting: A Practical Guide

Optimizely Frontend Hosting is a cloud-based solution for deploying headless frontend applications - currently supporting only Next.js projects. It...

Szymon Uryga | Jun 25, 2025

World on Opti ID

We're excited to announce that world.optimizely.com is now integrated with Opti ID! What does this mean for you? New Users:  You can now log in wit...

Patrick Lam | Jun 22, 2025

Avoid Scandinavian Letters in File Names in Optimizely CMS

Discover how Scandinavian letters in file names can break media in Optimizely CMS—and learn a simple code fix to automatically sanitize uploads for...

Henning Sjørbotten | Jun 19, 2025 |