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
How to fix scheduled job 'Remove Abandoned BLOBs' if it keeps failing

Optimizely inlcudes a job named 'Remove Abandoned BLOBs'. This post will help you fix it if it's no longer working.

Henning Sjørbotten | Sep 26, 2023 | Syndicated blog

Optimizely Web Experimentation Metrics

Within the domain of Optimizely Web Experimentation Metrics, the emphasis is on objective key performance indicators (KPIs) selected to assess an...

Matthew Dunn | Sep 23, 2023 | Syndicated blog

Optimizely For you Intranet

Having been at Optimizely and in the CMS industry for nearly 16 years I have seen clients’ intranet requirements go from a simple site just to hous...

Robert Folan | Sep 22, 2023

Vulnerability in EPiServer.GoogleAnalytics v3 and v4

Introduction A potential security vulnerability was detected for Optimizely Google Analytics addon (including EPiServer.GoogleAnalytics and...

Bien Nguyen | Sep 20, 2023