EPiServer Dynamic Content Helper

In EPiServer

This blog post is about making it easier to add dynamic content in EPiServer CMS. By inheriting from a dynamic content base class and specifying a type that should be used to persist the dynamic content state the serialization and generation of EPiServer property data fields are performed automatically.

Update: I had missed the Dynamic Content Contrib for EPiServer CMS by Allan Thraen which basically does the exact thing that the Dynamic Content Helper does – and with sprinkles on top. He beat me to the punch by more than a year. You live, you learn.

Background

I had the fortune recently of attending a forum of EPiServer developers preparing to take the certification exam for EPiServer CMS 6. The topic of the day was dynamic content. Whilst listening in to the discussions it became apparent that using dynamic content isn’t super-easy. The correlation between EPiServer property data fields and dynamic content state was an issue – and rightly so.

If you’re new to dynamic content then you should check out Ted Nyberg’s post on it. It’s a good start to understand how and why dynamic content should be used.

The purpose of dynamic content helper

Since dynamic content state and its relation to the property data fields was an issue I figured we should take that complexity out of the equation.

It should be easy to create dynamic content. So how do we make it easy? Well, we all know how to create simple classes, right? Let’s start there. What if we just could throw a class with properties into the mix and let a base class take care of the creation of property data fields and serialization for us?

In short:

  • Serialization and deserialization should be performed automatically
  • Property data fields should be generated for us from a pre-defined type

The end result

The code below shows how the dynamic content helper is used. We’ll go through what’s going on in a minute.

As you can see T is of type RssDynamicContentItem. The class looks like this.

And that’s all you need to do except actually rendering the dynamic content. The plumbing of serialization, deserialization and generating the property data fields is done for you.

RssDynamicContent explained

Let’s go through this one. T is the type of the class that should be used to generate the property data fields and used in serialization. In this case it’s a class named RssDynamicContentItem.

Next we override the RendersWithControl property and tell it that we are indeed going to render the dynamic content with a user control, next we load the control.

So far nothing out of the ordinary. Until we get to the DynamicContentItem which we have in the base class. This property is of type T – RssDynamicContentItem!

The RssDynamicContentControl user control (which I’ve left out for brevity) has a property of the same type, this way we can assign or dynamic content item control without doing any parsing.

RssDynamicContentItem explained

The DynamicContentHelper class will map the types of the public properties in the type supplied to persist the dynamic content data into property data fields automatically. But unlike Page Type Builder I chose the PropertyString instead of PropertyXhtmlString since I figure it’s more commonly used together with dynamic content. 

As you can see in the sample you can override the type mapping by slapping on a DynamicContentItemAttribute attribute and telling it to use PropertyXhtmlString instead.

How it looks in edit mode

The type of T dictates the property data fields generated. Using the RssDynamicContentItem class the dialogue will look like below.

EditorMode

And rendered like below!

EditorMode3

Behind the scenes

As you might have guessed a’lot of reflection is going on. The dynamic content helper goes through all the public properties of the class you supply and map them to property data types.

Here’s the mapping list. Recognize it? Yes, it’s from Page Type Builder! Thanks Joel! 🙂

With serialization up and spinning its magic we simply use XML serialization to serialize (and of course deserialize) our object. To prevent the editor from going haywire we store the XML as a base64 string. I borrowed that idea from Anders Hattestad.

Language support

By default the name of the property data field is used. This would be the same as the property in the dynamic content item class supplied. But since the base property class PropertyData implements TranslateDisplayName you can effectively add the property names to your lang files.

Let’s take MaxNumberOfItems from the RssDynamicContentItem class as example. The lang file for english would look like this.

In a standard installation you’d find this in the lang_EN.xml language file.

Registering the dynamic content to episerver.config

You will still need to register the dynamic content as usual in episerver.config.

Dangers & annoyances

It’s not all rainbows and ponies. For instance, if you would change the type of T then the serialization will at best act funny and not display your field – worst case everything breaks. Also, the XML serializer cannot serialize anything that implements IDictionary so we cannot use LinkItemCollection. 🙁

My recommendation is that if you use it then don’t create any scary dependencies on business objects that may change. Stick to simple classes only used for managing dynamic content.

Download the code

The project is built for EPiServer CMS 6 and is the platform I’ve had it testrun on.

Free for download here!

Final words & disclaimer

My hope is that this will make it easier to add dynamic content to an EPiServer website. You won’t have to bother with the plumbing and can go straight to the fun stuff of rendering your dynamic content.

I have borrowed ideas and code from Anders Hattestad, Joel Abrahamsson and Ted Nyberg . So kudos and thanks goes out to them.

The code is provided as is (and there’s not much error handling) and should be considered an alpha release. I’m more than glad to answer any questions but please don’t hold me accountable. 🙂

daniel
daniel
Developer
Recent Posts
  • The fact that LinkCollection implements IDictionary, and _NOT_ IXmlSerializable, is a disgrace! Someone at EPiServer should really do something about that! :), it shouldn’t be very hard, since the LinkCollection Dictionary only contains serializable information anyway.

    Call your local EPiServer employee, I know I will. 🙂

    Nice job by the way!

  • Do agree that it’s a bit messy to do Dynamic Content from scratch. Have you seen this solution by Allan? http://labs.episerver.com/en/Blogs/Allan/Dates/2009/2/Turn-your-User-Controls-into-Dynamic-Content/
    Apparently something like will be included in EPiServer 6 R2.

  • Thanks Stephan!

    Well color me surprised. I had actually missed that one by Allan. Thanks, Erik.

    If Allans DC-plugin is included in R2 it’ll be super-cool. 🙂

  • Great job Daniel!

    Something very similar to this is coming in CMS 6 R2. I will take a close look at what your’ve done and make sure our solution combines the best of yours and what we’ve done so far.

    /Paul.

  • Thanks Paul!

    Ping me if there’s anything you need!

  • Nice post as always Daniel. Don’t feel bad that the same problem has already been solved – that’s never stopped me from contributing 🙂 And Your solution actually looks like nicer code than the DCPlugin.
    But I can confirm the rumors. In R2, similar functionality is included, both a base-class to inherit from, an attribute for registering – and if the same attribute is applied to a user control or a web control, it’ll turn it into a DC as well.
    Also, in R2, all DCs when used, can be setup to only show to certain personalized visitor groups.
    What we really need now is a way to make editors understand what dynamic content is – it is thought provoking that 75% of all developers has tried to make one, but 75% of users have no idea what a dynamic content element is.

  • Thanks Allan!

    Hm. Good point! Maybe I should write up a post that is actually aimed towards web editors instead of primarily developers.

    In the community I can feel that we’re doing a’lot of really cool stuff code-wise but we could do a better job of including the actual users of our sweet functionality – the web editors!

    A ‘web editors WHY and HOW’ blog category. 🙂

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search