Vulnerability in EPiServer.Forms

Try our conversational search powered by Generative AI!

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
Join the Work Smarter Webinar: Working with the Power of Configured Commerce (B2B) Customer Segmentation December 7th

Join this webinar and learn about customer segmentation – how to best utilize it, how to use personalization to differentiate segmentation and how...

Karen McDougall | Dec 1, 2023

Getting Started with Optimizely SaaS Core and Next.js Integration: Creating Content Pages

The blog post discusses the creation of additional page types with Next.js and Optimizely SaaS Core. It provides a step-by-step guide on how to...

Francisco Quintanilla | Dec 1, 2023 | Syndicated blog

Stop Managing Humans in Your CMS

Too many times, a content management system becomes a people management system. Meaning, an organization uses the CMS to manage all the information...

Deane Barker | Nov 30, 2023

A day in the life of an Optimizely Developer - Optimizely CMS 12: The advantages and considerations when exploring an upgrade

GRAHAM CARR - LEAD .NET DEVELOPER, 28 Nov 2023 In 2022, Optimizely released CMS 12 as part of its ongoing evolution of the platform to help provide...

Graham Carr | Nov 28, 2023