Vulnerability in EPiServer.Forms

Try our conversational search powered by Generative AI!

Linus Ekström
Dec 5, 2012
(0 votes)

Changes for properties between EPiServer 6 and 7

The property system has changed quite a lot in EPiServer 7 and the need for writing custom properties has been greatly reduced. There have been many blog posts about the subject but here is a quick reference guide to help you move from the old property system to the new:

Task EPiServer 6

EPiServer 7

Additional reference
Validate values Write a custom property

Use the built in validation attributes or build your own

Custom storage of complex values

Write a custom property

Either use a block as a property or write a custom property
Change rendering Write a custom property and write a custom property control that implements CreateDefaultControls Write a custom property control or a user control inheriting from PropertyControlBase<T> and register it with the RendeDescriptor attribute.
Change editing Write a custom property and write a custom property control that implements CreateEditControls Register an EditorDescriptor and add a Dojo/Dijit based editor.


Additional hints

  • Check the new Alloy template for examples of how to write custom properties, register templates and editors.
  • If you want to let the editors have a selection or one or many choices this can be done on the server without having to create a custom editor. See:
  • There is still support for your legacy properties by using a web forms based dialog. If your property has the same value type as one of the built in properties (int, string, category, url, xhtml string etc) you need to add an UIHint attribute to your model, otherwise the default editor for the type will be used.
Dec 05, 2012


Thomas Krantz
Thomas Krantz Dec 5, 2012 11:50 AM

95% of our need for custom properties has been for "change editing", which we use frequently in all projects to help the editors. They have been used for things like popping up a Google map to select coordinates, editors for quickly building promo/slideshow slides, color pickers, autocomplete text input with multiple values, dropdown with some filtered list, etc.

These ordinary 1 or 2-hour tasks we're doing all the time, are now considered a minimum 8-hour "creating a more advanced property editor" task, requiring a black belt in Dojo/Dijit.

Just saying there's probably a need for something in between. I need it anyway, I spent 4 hours yesterday modifying the dijit.form.ComboBox widget.. :)

Dec 5, 2012 12:11 PM

I agree with Thomas that something more in between would be nice.

We have projects with many and complex custom properties. Rewriting all of them will be a big issue that will probably delay the upgrade to CMS7.

Dec 5, 2012 12:26 PM

Thanks for the feedback. We know that this is a challenge since it's both a change of technology (JavaScript as the main language) as well as a new framework (Dojo/Dijit). I personally think that it is possible help our partner developers without changing the main functionality, for instance through:

->More sample code for common editor types.
->Built in support for collection properties.
->Some frequently asked for editors like "Folder picker".
->More built in editors that can be configured, for instance selection editor that auto-connects to a store on the server so that you only have to create the store and not the actual editor.
->Intellisense support for the EPiServer and Dojo/dijit libraries.
->Debug versions of the scripts that are easilly installed on your environment.
->Conversion support for properties that store many values to block properties.

Joel Abrahamsson
Joel Abrahamsson Dec 5, 2012 12:51 PM

While I think what you write is valid Linus, I think a sort of wrapper for those that just want server->dom elements->minor javascript stuff->server would be useful. Using such you may not get all the bells and whistles that you otherwise would have but one could also skip all the boiler plate set up, finding the right mixins etc.

For instance, I think the amount of code needed for the custom editor (essentially a text area with some minor additions) in Alloy Tech looks a bit frightening compared to the value it adds.

Also, module.config _must_die_ :)

kayvan shaabani
kayvan shaabani Dec 5, 2012 04:47 PM

Thanks Linus

Please login to comment.
Latest blogs
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

A day in the life of an Optimizely Developer - OptiUKNorth Meetup January 2024

It's time for another UK North Optimizely meet up! After the success of the last one, Ibrar Hussain (26) and Paul Gruffydd (Kin + Carta) will be...

Graham Carr | Nov 28, 2023

Publish content to Optimizely CMS using a custom GPT from OpenAI 🤖

Do you find the traditional editor interface complicated and cluttered? Would you like an editorial AI assistant you can chat with? You can!

Tomas Hensrud Gulla | Nov 28, 2023 | Syndicated blog