Oct 29, 2008
(0 votes)

Using dynamic languages with EPiServer Community

So I'm at MS PDC in Los Angeles and yesterday I attended the session on the DLR (Dynamic Language Runtime) which got me thinking on its possibilities in the EPiServer Community framework. Dynamic languages have been around for quite some time, and those who are familiar with a dynamic language know the benefits, and the confusion involved. With a static language you know what you're getting, you know the properties that are part of your object and you know the type they expose.

If you at any time could change the existence of a property or change its type, life becomes confusing. But when you develop a product these days nothing that you deliver to your customers will ever fit perfectly into what they want - hence the Community attribute system (or properties in CMS) was developed. The community attribute system lets us dynamically specify the blueprint of an object but it also gives us some control because we can strongly type each one of our attributes. When we are using a static and predictable language like C# this works well - we can be sure of the type, but still they do not become part of the object in the same way as developers are used to with the statically created properties.

.NET 4.0 will introduce dynamic possibilities in C# by the static type "dynamic". The "dynamic" type will allow you to treat objects that are inheriting DynamicObject with a lot less constraints than you are used to and you could write something like this:

public class Company : DynamicObject
// implementation


dynamic d = new Company();
d.Founded = DateTime.Now;

but it also allows something as horrible as this:

d.Founded = "yesterday";

So how do we get the best out of both worlds? We want to dynamically create new properties on an object, but we would want some kind of type control. Luckily the whole process for implementing a DynamicObject is up to the implementor and the implementation is very similar to the attribute system (basically a collection of name-value pairs). If we would apply the same type control as we have today onto the implementation of DynamicObject, we would get a semi-dynamic object that would result in a far better scenario:

dynamic d = new Company();
d.Founded = DateTime.Now;
d.Founded = "yesterday"; // will throw since the definition expects the type DateTime

Sure, having gotten a compile error before this would have been ideal, but this is the result of merging static with dynamic.

Oct 29, 2008


Sep 21, 2010 10:32 AM

Nice post!
/ Paul Smith

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