London Dev Meetup Rescheduled! Due to unavoidable reasons, the event has been moved to 21st May. Speakers remain the same—any changes will be communicated. Seats are limited—register here to secure your spot!

Magnus Rahl
Apr 14, 2011
  4244
(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

smithsson68@gmail.com
smithsson68@gmail.com 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
Display page/block thumbnail based on selected site in multi-site solution

In previous blog we described how to control the visibility of the blocks or properties based on the current site in multisite solution. We can use...

Tomek Juranek | May 16, 2025

Understanding the Infrastructure Powering AI Agents for Marketing

The marketing world is increasingly captivated by the potential of AI agents. However, it's crucial to recognize that these agents are not simply...

Patrick Lam | May 15, 2025

Meet the Newest OMVPs – Winter 2025 Cohort

We're excited to officially welcome the latest winter cohort of Optimizely Most Valuable Professionals (OMVPs) - a group of passionate tech...

Satata Satez | May 14, 2025

Helper method to encode query string properly

When using Url.ContentUrl() in Optimizely 12, encodes spaces as + in the query string. If you want to encode the spaces as %20, use the below helpe...

sunylcumar | May 13, 2025