November Happy Hour will be moved to Thursday December 5th.

Linus Ekström
Dec 5, 2012
  6526
(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

http://www.david-tec.com/2012/06/EPiServer-7-Preview---Using-validation-attributes

Custom storage of complex values

Write a custom property

Either use a block as a property or write a custom property http://world.episerver.com/Blogs/Alexander-Haneng/Dates/2012/8/How-to-create-a-simple-Block-Type-in-EPiServer-CMS-7/
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. http://world.episerver.com/Blogs/Linus-Ekstrom/Dates/2012/10/Custom-renderers-for-properties/
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. http://world.episerver.com/Blogs/Linus-Ekstrom/Dates/2012/11/Creating-a-more-advanced-property-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: http://world.episerver.com/Blogs/Linus-Ekstrom/Dates/2012/9/EPiServer-7-Configuring-editors-for-your-properties/
  • 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

Comments

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
AsyncHelper can be considered harmful

.NET developers have been in the transition to move from synchronous APIs to asynchronous API. That was boosted a lot by await/async keyword of C#...

Quan Mai | Dec 4, 2024 | Syndicated blog

The search for dictionary key

Recently I helped to chase down a ghost (and you might be surprised to know that I, for most part, spend hours to be a ghostbuster, it could be fun...

Quan Mai | Dec 4, 2024 | Syndicated blog

Shared optimizely cart between non-optimizley front end site

E-commerce ecosystems often demand a seamless shopping experience where users can shop across multiple sites using a single cart. Sharing a cart...

PuneetGarg | Dec 3, 2024

CMS Core 12.22.0 delisted from Nuget feed

We have decided to delist version 12.22.0 of the CMS Core packages from our Nuget feed, following the discovery of a bug that affects rendering of...

Magnus Rahl | Dec 3, 2024