Magnus Rahl
Apr 14, 2011
(2 votes)

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.

Apr 14, 2011

Comments Apr 14, 2011 04:26 PM

I've reported this as a bug. Sorry for any inconvenience.

Magnus Rahl
Magnus Rahl Apr 14, 2011 05:36 PM

More a weakness than a bug perhaps, no worries :) But make sure any new implementation is backwards compatible.

Please login to comment.
Latest blogs
Customizing Property Lists in Optimizely CMS

Generic property lists is a cool editorial feature that has gained a lot of popularity - in spite of still being unsupported (officially). But if y...

Allan Thraen | Oct 2, 2022 | Syndicated blog

Content Delivery API – The Case of the Duplicate API Refresh Token

Creating a custom refresh provider to resolve the issues with duplicate tokens in the DXC The post Content Delivery API – The Case of the Duplicate...

David Lewis | Sep 29, 2022 | Syndicated blog

New Optimizely certifications - register for beta testing before November 1st

In January 2023, Optimizely is making updates to the current versions of our certification exams to make sure that each exam covers the necessary...

Jamilia Buzurukova | Sep 28, 2022

Optimizely community meetup - Sept 29 (virtual + Melbourne)

Super excited to be presenting this Thursday the 29th of September at the Optimizely community meetup. For the full details and RSVP's see the...

Ynze | Sep 27, 2022 | Syndicated blog