Embedding EPiServer language files

One of the things that I’m always aiming for when creating a module for EPiServer is that you should be able to install it simply by dropping a single assembly to the bin folder. There should be no or very little configuration needed (Convention over Configuration!)  and you shouldn’t have to place files in folders here and there.

The first and probably most important step towards this goal was introduced to the wider EPiServer audience by Dan, Johan and Allan quite a while back ago, where they showed how to reference embedded .aspx files using a virtual path provider.

At Intergen were I currently work we are using this technique frequently and as of late we also introduced a standard way to embed EPiServer language files within these module assemblies, the MetaPropertyModifier that I wrote about the other week is built with embedded language files. The key requirements that we set up for this was that it should still be possible to add more languages later and also possible to override strings in the included languages.

Scheduled jobs in EPiServer CMS 6

There are a few hidden bits in EPiServer CMS 6 that hasn’t been talked much about, one of them being the enhancements to the scheduled jobs. These new features include the ability to interrupt the execution of a long running job and for these jobs to send status updates to the UI.

Modify the built-in EPiServer properties

When you are creating a page type in EPiServer you have a lot of configuration settings you can do. You can set the default value, hide it from the Edit interface, make it mandatory and so on. For the built in properties it’s another story, you can set the default values for some of them, but that is pretty much it.

Probably the most common request for this functionality is how to hide the categories property/tab as it doesn’t make sense to display it if you are not using categories on your site. The same logic would apply to the URL segment property if the site for some reason doesn’t have Friendly URLs turned on. Mari Jørgensen wrote a blog post when EPiServer 5 was release on how to hide the categories property and Fredrik Haglund also wrote a piece on how to move properties to another tab.

EPiServer Extension methods, part 1 of many

So Frederik Vig started a community project around EPiServer Extensions which I believe is a great initiative. Already having a great number of extension methods that we are currently using.

Rather than just dump them in the source code repository I thought I would try to get my blogging going again by posting each method with a short blog post so that people can comment easy and come with suggestions for improvement

A quick comparsion between FindPagesWithCriteria and a recursive GetChildren

On the project I’m working on at the moment there are plans to do a lot of page retrieving based on categories. My initial thought was to retrieve all pages for that section and to the filtering in memory. Possibly with some pre-filtered and cached collections to speed it up, but since the categories in this case can be combined quite freely, the hit rate on this cache would probably be quite low. Reading Steve’s article about FindPagesWithCriteria and Performance I decided to do some quick unscientific tests on the differences between using FindPagesWithCriteria and a recursive GetChildren implemented as shown below using LINQ filtering to select categories.

EPiServer property settings in the Help text field

In one of my previous posts I listed a number of suggested improvements to the EPiServer property system. My number 1 wish (Just after wish 0) was that there would be a settings property on page definitions. While being nothing like a native solution with a dedicated interface would be, I thought I would show you a simple way to use the help text field to store settings for your EPiServer page properties. I’ve seen this approach being mentioned before around the web but I never got around to use it myself as I always found it somewhat tedious to manage these settings in the admin mode. Since starting to use the PageTypeBuilder by Joel Abrahamsson this has somewhat changed and now there is a possibility to define help texts through attributes in your code, making them much easier to manage.

Therefore I thought that I would share with you how I have implemented EPiServer property settings through the help text field.

Quick update my ‘nice feel’ custom property

I just wanted to follow up on my previous post on creating an ‘nice feel’  custom EPiServer property that I posted a few weeks ago. Got some great comments and thought I would follow up with an updated version of my example property.

First, you can find the new source code here: PropertyPageTypeList, PropertyPageTypeListControl

I’m going to let the code speak for itself, but I can highlight a few key changes:

• It’s now inheriting directly from PropertyData instead of PropertyLongString
• I renamed it from collection to list and exposing the PageTypeCollection as an IList<PageType>
• It’s now allowing changes to the PageType list property that will be persisted when saved.
• I have made a number of smaller changes to prepare for the creation of a PropertyObjectBase and PropertyObjectListBase. I will post these very soon, possible on EPiCode if there is any interest?

Again thanks for the previous feedback. Let me know if there is any more things you would like to see improved!

My top 15 wishes for the EPiServer Property framework

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!

Creating an EPiServer Custom Property with that nice feel to it

With the latest versions of EPiServer, creating a custom property is not especially complex anymore and it has been covered in lots of posts. There is one aspect of custom property creation that I think is lacking and that is using a real value type. With that I mean that the Value property of that PropertyCar should return a Car object and not the base type, for instance a String if you inherit from the LongString property for example. I know that I might be a bit picky with this but it gives the property just that extra nice feel. Even EPiServer with it’s latest creation LinkCollection doesn’t do this, instead Value returns the raw data string that is stored in the database.

So how do we get that nice feel? It is a bit harder than you would expect at a first glance. I’m going to walk you through how I created a multiple page type selector who’s Value property returns a PageTypeCollection. We’re going to inherit from PropertyLongString and save the GUID of the selected page types in a comma separated string. I won’t go into any detail around how to do the standard stuff like overriding CreatePropertyControl, others have gone into details around that already.

Starting with the basics we’ll override the PropertyValueType:

public override Type PropertyValueType
{
    get { return typeof(PageTypeCollection); }
}

Since our main goal was to get the Value property to return a PageTypeCollection we need to override that. To make this easy we’ll let it be a wrapper around a separate property of PageTypeCollection type that handles the conversion to and from a string.

One key thing when working with collection is that you either need to track if the items in the collection changes or have a read-only collection with read-only items in it. The former is not always possible if you are working with a collection that you don’t have control over like in our case. The CreateGuidList and ParseGuidList are helper methods that serializes/deserializes a PageTypeCollection to the GUID string.

private PageTypeCollection _pageTypes;

public PageTypeCollection PageTypes
{
    get
    {
        if (_pageTypes == null)
        {
            _pageTypes = ParseGuidList(base.LongString);
        }
        return _pageTypes.AsReadOnly();
    }
    set
    {
        base.ThrowIfReadOnly();
        if (value == null || value.Count() == 0)
        {
            base.Clear();
        }
        else
        {
            base.Modified();
            _pageTypes = new PageTypeCollection();
            _pageTypes.AddRange(value);
            base.LongString = CreateGuidList(_pageTypes);
        }
    }
}

public override object Value
{
    get { return this.PageTypes; }
    set { this.PageTypes = value as PageTypeCollection; }
}

Then we need to ensure that if the LongString value changes or the SetDefaultValue is called, the page type property will be reloaded. If you don’t do this, using this property type for a Dynamic property will easily break inheritance. I also used the same technique in CreateWritableClone to ensure that it won’t use the same PageTypeCollection.

protected override string LongString
{
    get
    {
        return base.LongString;
    }
    set
    {
        _pageTypes = null;
        base.LongString = value;
    }
}

protected override void SetDefaultValue()
{
    base.SetDefaultValue();
    _pageTypes = null;
}

public override PropertyData CreateWritableClone()
{
    PropertyPageTypeCollection property = (PropertyPageTypeCollection)base.CreateWritableClone();
    property._pageTypes = null;
    return property;
}

One important piece in the puzzle is to override the LoadData and SaveData methods. This is because the EPiServer data access layer doesn’t actually look at the value type but at the Type property so it will expect a string. We can make it easy for ourselves and just use the Value property of the base class since this is what the LongString property uses.

public override object SaveData(PropertyDataCollection properties)
{
    return base.Value;
}

public override void LoadData(object value)
{
    base.Value = value;
}

Finally we override ParseToObject and ParseToSelf and create a new static Parse method to make the property API work more as people would expect.

public override PropertyData ParseToObject(string value)
{
    return Parse(value);
}

public override void ParseToSelf(string value)
{
    this.Value = Parse(value).Value;
}

public new static PropertyPageTypeCollection Parse(string value)
{
    PropertyPageTypeCollection types = new PropertyPageTypeCollection();
    types.PageTypes = ParseGuidList(value);
    types.IsModified = false;
    return types;
}

And that’s it! I have implemented IEnumerable<PageType> to make it even easier to use but that is not neccesary at all.

My only regret is that I haven’t found a way to make the PageTypes property writable when the property is writable, but if you have a nice solution to this I’d love to hear about it!

You can find the complete source code here: PropertyPageTypeCollection, PropertyPageTypeCollectionControl

Update: Have posted a quick update with updates to this custom property here.

PageTreeIcons is picking up some speed

Since my last blog post about my EPiServer module PageTreeIcons, a number of things have happened that I thought I share with you really quickly (its half past twelve here and I have a release to do 7am tomorrow morning).

• Published PageTreeIcons on epicode. Everything went really smooth, easy as to add source code and wiki pages by following their instructions on how to contribute. I would recommend everyone that is working on EPiServer to dig around and see if they can’t contribute with anything there! Also big thanks to Steve Celius at for your help!
• Then some really nice comments from one of the other guys at BV Networks, Stein-Viggo Grenersen. He also added a request to include the target page name in the LinkType handler tool tip.
• Added target page name to the LinkType handler tool tip and released and published version 0.2 of PageTreeIcons. The EPiServer page tree didn’t want to let me add a link to the page that updated the page tree easily, so that is left for the future.
• Another post by Stein-Viggo that included PageTreeIcons, now featured on the EPiServer Labs blogs. This time voting for me as EMVP! I am truly honored, but I myself think I need improve my visibility a bit more. But I have a ton of cool ideas for EPiServer modules to build and publish. Stay tuned!
• Super-Viggo is on a roll, adds a Screencast of PageTreeIcons to the epicode site!
• PageTreeIcons is now the featured module on epicode front page!
• Finally, beeing the featured module inspired me to write up some documentation on how to configurate the PageTreeIcons module and add that to the epicode wiki as well. Next on line is a write up on how to create your own tree icon handler. My documentation skills are getting up to a state that I just can call them slightly horrible.