My top 15 wishes for the EPiServer Property framework

April 4, 2009

Perhaps the most central part of the EPiServer CMS is the page property framework. It allows a developer to quickly create a website, concentrate on the front-end and get a great and easy to use management system. The property framework in EPiServer has been around for as long as I can remember (that would be around the end of 2003) and from what I know, quite some time before that as well. It got a update with the release of EPiServer 5, but otherwise it really hasn’t changed much. It is so useful and such a core part of every EPiServer site that I feel that they must be in desperate need for a little attention real soon!

Looking at some of the blog post over the last year or so reveals that there are developers out there that are trying to break the constraints of the current system. I’m primary thinking of Mr. Hattestad with his MultiProperty and Properties on Properties and Mr. Nordin‘s MultiPage property but I’m sure there are a lot of others as well.

So here EPiServer, I want to present you with my wish list on things I would like to improve with the page property framework. I’ve thought of these for a while but never really shared it with anyone but my colleagues and since they are tired of hearing about it now I thought I find myself a bigger audience that can agree with me and put some pressure on you. Well, who knows, some of there wishes might already be on their way and possibly already talked about at the latest EPiServer Day (sorry, missed out on that one. It’s a long trip from NZ!). I’ll try to be constructive and give you some use cases as well as ideas on how to implement them! And I know that some of these already are implemented in snippets around the web and that I probably could write a plug-in for others myself, but core support is important!

Without further ado, somewhat prioritized but not really:

1. Custom property settings

Almost don’t have to explain this one, but every time I’m trying to explain it to customers why they can’t set the maximum length of that input field themselves I suddenly feel very inconvenient. Besides setting the maximum length on a string I want to set the range for an integer and the page type for page selection to mention a couple. There was a good reason for why it was implemented for the LongString property and same reason exist for other properties! Just give each property type a possibility to return a Settings control and a string for storage in the database, that’s all we ask for! Pretty please!

2. Clean up MS Word HTML

I know that a new HTML editor is on it’s way so I left that one out from grabbing the top spot on the list. I just hope that the new one has a simple tool for removing MS Word HTML. Unfortunately it still is very much needed.

3. Hide standard properties

This might seem like a trivial request but behind it hides something really useful and this is when you are using EPiServer pages as a representation for other things than pages. The better the performance gets in EPiServer I have started to use it as a generic ORM to store arbitrary data. The problem is that all those properties that are only relevant when we are talking about a page really seem to confuse some editors. An easy way to hide them per page type just like other properties would help a lot here and really boost this type of usage!

4. Property groups

Look at this one as the need for small groups of properties without having to create my own custom property with it’s own dialogue. The image with a caption that links to a page becomes a group of three properties (imageurl, captionstring and targetpage) in a fieldset with a nice legend text set. The tabs takes care of the large bits but to many tabs doesn’t really work that well. Having worked a lot with Extension, ehum, EPiServer Composer, I have seen how dividing properties in to logical groups really help editors instantly understand how things are connected. Oh, and I’m tired of prefixing properties with things like “Theme image – Image”, “Theme image – Caption” and “Theme image – Link target” over and over again.

5. Checkbox that control dynamic property inheritance

Please implement a checkbox that controls if a property inherit from the parent or not. I want to set a false value on that boolean property and I want to set that string to empty further down in that page tree. A checkbox is all I need, I can trade it against the * ^ ? symbols any day of the week!

6. Usage without the property control

In many ways EPiServer has gone towards separating the API from the front end, with version 5 you could start to use standard ASP.NET controls to a whole new extent, great! But there is one last fortification that even has grown stronger lately and that is the Property control. Examples here are the XForms and XhtmlString properties, especially the latter with the invention of Dynamic Content that gets replaced in the Property control. If I want to display a XHTML string with Dynamic content in some other context where I can’t use the property control I would have to recreate the code that is encapsulated in the property control. Think MVC here and remove the need for controls!

7. Admin page type properties

Image that you have built this amazingly cool template that you can configure to do all kinds of crazy things. Now you just want to let administrators manage these properties so that you could use the same template for several page types or reuse the template from another project. Complex settings are hidden from everyday usage for editors and while the template still is able to match a lot of different use cases. The potential for template packaging just went through the roof!

8. Full globalization support for dynamic properties

Why does dynamic properties have to work in a different way than the page properties when it comes to globalization? I can come up with any reason not to put the language menu on the dynamic properties page as well.

9. Global site properties

Every project there is need for global properties that can be edited. With global properties I mean properties one per site properties. Traditionally these have been placed in the Dynamic Properties but lately the public templates have made the use of properties on the start page more popular. Counting the time I have had to explain where these configuration properties are stored I must question the usability of both these solutions.

10. Simplify the PropertyData object

I know that it has evolved over the years, but it’s about time for some refactoring soon. Getting your head around the ins and outs of how properties are loaded and saved and parsed are a challenge every time. It got better with v.5 but there are still a long way to go.

11. Split the PropertyControl in two or three controls

One thing I never understood when the v.5 property update was released, was why create a PropertyControl that handles both the edit mode and the presentation mode when it easily could been split up in two separate controls with separate concerns. I know it might seem a silly thing to ask for, but I want to keep my edit and presentation mode split up!

12. Selectable display control

This wish could be seen as a mix of Property settings and the PropertyControl split and it is to make the control that is used to render the property in view mode selectable. This would open for some nice packaging of display controls that are independent of the property data. A page property could be rendered as a page list with one control, as a teaser block with another or just as a plain link as default. Combine this with some property settings and we have a winner. Should this be higher up in the list possibly?

13. PropertyObjectBase and PropertyObjectCollectionBase

I’ve had these on my todo list forever, so since I never get around to build them myself I thought I might ask someone else to. What I want is two base property that makes it really easy to save any (serializable) object or collection in a property. And why not save it in a field in the database that never have to be searched or indexed.

14. Tabbed admin interface

Since the properties are sorted by tabs in edit mode, why not do the same in admin mode? Would definitely give a better overview and make sorting more intuitive. Add an “All” tab in the end if really needed.

15. Search weight

As it is now all searchable properties currently equally important when it comes to search ranking. Adding an integer that can give one field higher priority when searching would be quite handy. I know that the real recommendation is to use a better search engine, but all clients doesn’t want to pay for it so the standard one have to do for now.

Thanks EPiServer for listening! And the rest of you, please leave a comment as I’m sure you have your own additions or comments to my list. And if there isn’t too many people calling me a big whiner I might complement this with a list of the overall top things I would like to see in future versions of EPiServer.

Over and out.


It don’t know how this one slipped my mind, but anyhow:

0. Strong Typed Properties

Yes, on top of the list should of course be strong typed properties using generics, enough said.

13 Responses to “My top 15 wishes for the EPiServer Property framework”

  1. Morten Says:

    Nice list!

    My number one is as yours, strongly typed properties and I would like to add strongly typed pagetypes.
    Mr. Libardo who wrote N2 now works with EPiServer so he might have some influence :-)
    N2 is one great CMS!


  2. Anders Hattestad Says:

    Nice list, good blog!

    Some of them I would disagre with you (like search weight) should be there but most of them are really needed. Some of them are doable in the existing framework, but not very practical.

  3. hn Says:

    I agree, strong typed page types would make a big difference. Having worked close with Cristian I know that he builds some great stuff, so lets hope for that!

    Yeah, I can agree that search weight is not that important for me either, last on the list as it is haha, but I had quite a few clients asking me how they can make for example the MainBody count for more than the SecondaryBody in search queries, so that is why it’s there.

    And to both of you, big thanks!

  4. Mattias Says:

    Thanks for the feedback Henrik!
    Just wanted to say that we’re reading what you write and we’re trying to squeeze in as much as we can into each release.

    And please be nice to the new Swede down there ;)

  5. Erik Nordin Says:

    Nice list Henrik!

    Strong typed properties and a way to add validation and settings to properties would be awesome. I really hope EPiServer will put some effort into this to the next release.

  6. Ted Nyberg Says:

    I can sign this petition too! :) Two notes though: when it comes to search for providing local site search, use another search engine! ;) The EPiServer search logic should be used for template logic, not for providing organic search results to users. Did I mention Search Server 2008 Express is free? ;) And can we put easy sorting of properties on the wish list? :P

  7. hn Says:

    Any day! I’ll better start writing that other list with other ideas! And don’t worry about the Swede, we’ll sort him out!

    Thanks! I’m sure they will!

    I agree, for search that should always be the priority. But the site search is there, and it’s sometimes the only thing clients are willing to pay for, in terms of implementation time that is.
    Hope I can get some time soon to follow up on your Search Server post from some time ago.
    And didn’t it sound like better sorting was on it’s way?

  8. Ted Nyberg Says:

    I want drag-and-drop sorting of properties, in addition to grouping and tabs in the admin interface. But maybe there’s something around the corner that I’ve missed?

  9. Robor Says:

    Thanks for article. Everytime like to read you.

  10. Hi!

    Nice blog post. Although I can not give away anything at the moment I urge you to check out the EPiServer CTP2 release that will be released as soon as testing has been done. I have some blog posts awaiting this release that will describe some updates to the property framework which I think you will like.

    • hn Says:

      Linus, that sounds great, I’ll definitely check it out as soon as it arrives.

      Having said that, as of lately another old peeve among the properties has been haunting me, and that is the lack of real collection properties, i.e not serialized in long string text fields.

      With a bit of luck, I’ll get this too… :)


  11. ACCEQUALI Says:

    I really enjoyed reading your blogpost, keep on making such exciting posts!!

  12. […] more: My top 15 wishes for the EPiServer Property framework […]

Comments are closed.

%d bloggers like this: