linuse
Dec 5, 2012
  5751
(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
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