Dynamic content is deprecated in Optimizely Content Management System (CMS 12). Use blocks instead. While existing solutions will continue to work, you should not build new solutions on this API. It will be phased out in the future.
The [DynamicContentPluginAttribute](🔗) simplifies development and registration of a Dynamic Content class by eliminating manual registration of your Dynamic Content class in the **episerver** section of _web.config_.
Only classes that implement [EPiServer.DynamicContent.IDynamicContentBase](🔗) may be decorated with this attribute, otherwise the application generates an error during startup. However, decorated classes that derive from `
System.Web.UI.Control` implicitly implement `
[DisplayName](🔗) and [Description](🔗)
DisplayName` is a string used to identify the plug-in in lists.
Description` is a short text that describes what the Dynamic Content type does.
[Url](🔗), [UrlFromUi](🔗), and [UrlFromUtil](🔗) `
Url` specifies the path to the user control that handles editing of the Dynamic Content type. You only have to provide one of these values, choose the attribute that best matches the location of your editing control, use `
UrlFromUi` if the control is located somewhere below the UI folder. The `
UrlFromUi` and `
UrlFromUtil` attributes require relative URLs and the `
Url` attribute should have a application relative URL (_~/SomeFolder/MyEditControl.ascx_).
If you develop your Dynamic Content plug-in as a Control, you may choose to not define values for any of the URL attributes, which causes the application to automatically generate a control for editing your Dynamic Content settings.
[ViewUrl](🔗) ViewUrl specifies the path to the user control used to render the Dynamic Content type for visitors. This URL can point to the Dynamic Content plug-in itself provided it is implemented as a User Control.
The following example shows a class inheriting from `
UserControl` that is decorated with the [DynamicContentPlugInAttribute](🔗). Because the class inherits from `
UserControl` you do not have to implement any interfaces, an implicit implementation of `
IDynamicContentControl` is automatically generated based on the settings of the `
DynamicContentPlugInAttribute` and the class public properties.
The value of `
ViewUrl` is an application relative URL that points to the markup file of the control; the rendering of the Dynamic Content for visitors is handled by the control itself.
No edit interface URL (`
UrlFromUtil`) was specified, so an editorial interface is automatically generated based on the public properties of the class. Only properties of the following types that have public get and set included in the editorial interface:
Types derived from [EPiServer.Core.PropertyData](🔗)
The basic markup of the user control in the following example is just for illustration purposes.
Because the class is decorated with the `
DynamicContentPlugInAttribute`, the plug-in is automatically registered and ready for use when the application starts. The following example shows the plug-in in the editorial interface.
The following example shows the output for a visitor.
## Add MVC support for a dynamic content plug-in
You can make a dynamic content plug-in support MVC in the following ways:
Create a display template with the same name as the dynamic content plug-in.
For the `
DynamicPageProperty` plug-in, the name is _DynamicPageProperty.ascx_ or _DynamicPageProperty.cshtml_. The view takes the dynamic content plug-in as the view model, and renders the dynamic content in view mode. The following example shows a simple dynamic content (_DdsViewerDynamicContent_), and a razor view for rendering the content.
Let the plug-in implement the interface `
System.Web.Mvc.IView`, which is exactly what the `
DynamicPageProperty` does. The interface only contains the method `
Render`, with a `
ViewContext` object and a `
If there is a display template with the same name as the dynamic content plug-in, and the plug-in implements IView, the system calls the display template and ignores the IView implementation.