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
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.. :)
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.
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.
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_ :)
Thanks Linus