Property problems in DynamicContentBase / Control-based Dynamic content

In EPiServer CMS 6 R2 there is a new possibility to easily create Dynamic Content plugins from (User)Controls just by decorating them with an attribute. The idea has been implemented outside EPiServer for previous versions, for example here. The new “official” approach is described in this tech note.

State storage

Dynamic content plugins are required to persist their state (if any, you could implement stateless dynamic content which for example fetches information from a fixed resource) as a string. In the “classic” pattern you implement the state serialization yourself.

In the Control-based pattern the Framework does this for you. All you need to do is to give your Control public properties of any type that inherit PropertyData and they will be persisted (currently there’s a bug with PropertyXhtmlString though). There are also some shortcuts for strings, integers etc., read more in the tech note.

The design of this state storage isn’t optimal for all situations though…

Problems with state storage and adding properties

The state storage of Control-based properties is handled by the EPiServer.DynamicContent.DynamicContentAdapter<T> generic class, inheriting from DynamicContentBase in the same namespace. The latter contains the code persisting the state and what it does is to loop over the properties and store a base64-encoded string for each, separating the substrings with pipes (‘|’).

Upon deserialization the properties are again looped over and the state string is split and decoded. But if you have added properties to your class “above” any of the exiting properties in the class the state will be restored to the wrong property! This is because the properties are not distinguished by anything other than their order.

So if you would decide to update your dynamic content by adding, say, a Heading property and place that at the top of the file (because you want it at the top of the Dynamic content editor) all your existing inserted dynamic content would be reduced to a smoking pile of junk, more or less.

Lesson learned

Don’t add properties to dynamic content plugins based on DynamicContentBase that is already in use. Or if you have to, add them last in the class. Or override the State property (not possible for Control-based DC). Or start out with your own implementation and state storage that you can do your best to future-proof and make backwards-compatible updates in.