• The bounds factor – proper use of Enum type guarantee that the selected value will fall within the constraints of the allowed value set.
• The ability to treat Enums as flags (and compound them into flag sets) as well as a one-of selector.
• The ease of use and potentially complete separation of the “Enum value” from the underlying machine type representation that ensures the most efficient memory usage.

Surprisingly enough EPiServer as it stands right now does not have an easy facility to turn Enums into properties. To give credit where credit is due, the EPiServer framework provides a nice surrogate that mimic that behaviour to a degree. The relevant property types are:

• PropertyAppSettingsMultiple  – which “creates check boxes with options that are defined in the AppSettings section in web.config. The name of the property should match the key for the app setting.”
• PropertyAppSettings  – which “creates a drop down list with options that are defined in the AppSettings section in web.config. The name of the property should match the key for the app setting.”

You quickly realize though that the properties have some limitations that makes their use a bit less compelling:

• The properties are not strongly typed
• The property entry in AppSettings section has to have the name that matches the property name on the page.
• It’s rather poorly documented, Other than relating to this blog entry or Erik’s post documenting it I could not find any other examples on how to use them. (but then again, who needs docs really when we have Reflector)
• You cannot have the very same property duplicated on the page since you can only have a single property of a given name per page. So you need to have multiple entries in AppSettings that match the name of each of those properties on your pages. I know… semantics but still…
• You are working on strings rather than enums (Did i mention it’s not type safe?)
• The values in the AppSettings are stored in a somewhat DLS-y manner (consecutive options are separated from each other with the ‘|’ character, the name and the value are separated with a ‘;’, for example: <add key = "RegionId" value="First Option;Option1|Default Option;Option2|Disabled Option;Option3" /> ) and I have had on an occasion entered a string there that caused the server to crash.
• The values are not translatable, or at least I could not find how to do it and any Reflector digging rendered no results either.

The solution to the problem:

The solution that the blog post describes is:

• Type safe
• Supports UI localization
• Easy to use in your custom implementation
• Flexible in allowing you to switch between the Enum being multi-choice or a single choice solution
• fully defined in the code – no need to modify web,config.

All you need to do to create your own custom Enum property is declare it.

using Cognifide.EPiserverControls.EnumDropDown;

[PageDefinitionTypePlugIn(DisplayName = "Sample Enum Property")]
public class SampleProperty : PropertyEnumSelector<MySampleEnum>
{
}

That’s it, really!

Now if you want to customize it; obviously you need to provide the information for the property to work with. But let’s stop for a while and think, where does that information belong?

• The property should worry about the mechanics of editing and the tediousness of persistence of the edited value, it clearly is not the place to specify the link between the Enum type and its human friendly drop down text.
• Web.config is for settings, not for describing content types and definitely not to enforce the property names.
• So where should the metadata around your Enum type be? How about we put it around the Enum type itself?

[Flags]
public enum MySampleEnum
{
  [ValueVisualisation(Name="First Option", LanguageKey="/enum/first")]
  Option1,

  [ValueVisualisation(Name="Default Option", Selected=true, LanguageKey="/enum/second")]
  Option2,

  [ValueVisualisation(Name="Disabled Option", Enabled=false, LanguageKey="/enum/disabled")]
  Option3,

  [ValueVisualisation(Name="Hidden Option", Hide=true, LanguageKey="/enum/hidden")]
  Option4,

  [ValueVisualisation(Name="Fifth Option", LanguageKey="/enum/fifth")]
  Option5,

}

What does all that do?

The property using an Enum described this way will look the following way in EPiServer:

Let’s get into the what’s happened here as there’s more than catches the eye.

As you can see the enum values are named like they are in the attributes describing them, Default option is selected just like you could have expected by looking at the Selected=true in its attribute. The Enabled=false in the Disabled option results in an option that cannot be changed. The unchangeable option can be both unselected or selected by default. You may want to disable some deprecated options but still show them in the UI as a legacy but for some reason you might not want users to be able to change their value. Option4 is clearly missing, which is intended and specified by the Hide=true, as you might want to hide options that have been removed form the UI and on the same time you don’t want to loose compatibility with a legacy API that uses the option.

Also There is one thing about the first option on the list – it’s translated! The mechanism to specify the translation is based on the standard EPiServer localization files that you can find in the “lang” folder in your typical EPiServer installation. The Translation for the property looks like the following

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<languages>
  <language name="English" id="en">
    <enum>
      <first>First Option Translated EN</first>
    </enum>
  </language>    
</languages>

so you see the value will take its translation key from the LanguageKey="/enum/first".

Ok, so we have the PropertyAppSettingsMultiple replacement, but what about PropertyAppSettings?

So here I reach the place where I am not 100% certain whether I took the proper path but I am sure I will hear about it if I didn’t :) The place where the property determines if it’s supposed to allow for multi selection or not is whether the Enum is marked with the [Flags] attribute. Obviously Flags mean that the property is a form of a bit flag and should be able to allow the user to flip the bits independently rather than being the “one-of” type. So once you remove the [Flags] form your enum you’re going to see it rendered the following way:

But hey, it’s not a one way trip, if you decide that you want the enum rendered in another type of property and force the opposite behaviour you can always override it in the derived property like follows:

    [PageDefinitionTypePlugIn(DisplayName = "Sample Enum Property Checklist")]
    public class SamplePropertyChecklist : PropertyEnumSelector<MySampleEnum>
    {
        static SamplePropertyChecklist()
        {
            MultiSelectEnum = true;
        }
    }

so even if you think my usage of [Flags] is faulty, the damage can be undone :)

Ok, but what about the enums that we have no control over – like enums form libraries. Obviously cannot retrofit attributes into them. Well, true but we still can have all of the control over the property.

Let’s assume for a moment that this is our legacy enum:

public enum MySampleLegacyEnum
{
  Option1,
  Option2,
  Option3,
  Option4,
  Option5,
}

You can just do nothing and simply use it in the property but the UI will display the not so nice Option1… names. That can be easily fixed – Again, specifying translation is the easiest way of achieving that goal. An xml for that enum would look like follows:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<languages>
  <language name="English" id="en">
    <MySampleLegacyEnum>
      <Option1>First Option</Option1>
      <Option2>Default Option</Option2>
      <Option3>Disabled Option</Option3>
      <Option4>Hidden Option</Option4>
      <Option5>Fifth Option</Option5>
    </MySampleLegacyEnum>
  </language>  
</languages>

The default values can be added by retrofitting the “DefaultValues” list with the elements that you want selected in the scenario where the property is first displayed for editing. You can also modify the inherited AvailableItems list to set the rest of the properties otherwise adjustable by the attributes.

Following is a sample of such retrofitted rules to match our original attribute-defined-enum.

[PageDefinitionTypePlugIn(DisplayName = "Sample Legacy Enum Property")]
public class SampleProperty : PropertyEnumSelector<MySampleLegacyEnum>
{
    static SampleProperty()
    {
        MultiSelectEnum = true;

        // Make Option2 a default selected value
        DefaultValues.Add(MySampleLegacyEnum.Option2.ToString());
        AvailableItems.Where(p => p.Value == MySampleLegacyEnum.Option2.ToString()).First().Selected = true;

        //Disable selection of Option3
        AvailableItems.Where(p => p.Value == MySampleLegacyEnum.Option3.ToString()).First().Enabled = false;

        //Remove hidden Option4
        AvailableItems.RemoveAll(p => p.Value == MySampleLegacyEnum.Option4.ToString());
    }
}

The [code for the EnumProperty] as well as [the compiled binaries] are available as Open Source and you can incorporate it in your projects as long as the Cognifide namespace is used for the code.

What do you think? Is that going to be useful for you?

Well I have… and I’m sure I will. And so did Fredrikj on the our #epicode IRC channel ;).

Basically I had the tool that would convert from one language to another, but Fredrikj requested something that would switch master language of a page from one to another. Since I’ve already had some of the work done, I’ve updated the stored procedure I’ve written some time ago and slapped a nice GUI up on it. Here’s the result:

What the tool allows you to do is perform either language conversion or master branch switching on a selected page and all of its children (if you choose so).

The stored procedure have been updated to work on CMS5 R2 (will no longer work on R1 – but if you need that functionality, comment here or give me a shout and I’ll create a compatible version for you).

A word of caution though – I take no guarantee whatsoever about its operation. Especially, if you wreck your client’s database with it. I did what I could to prevent some of the obvious problems (like switching to a non existing master or converting to an existing one) but I will not be responsible if it won’t work for you. make a database backup and experiment there before you do any changes on the real data. That said – it works for me, so I think it should also work for you.

You can download the archive containing the tool here. unzip it to your EPiServer web application folder keeping the folder structure or the plugin reference will be wrong. Include the *.aspx and the *.cs files in your project and apply the SQL file to your database (The manipulation is performed by a stored procedure located in the file).

Also if you’re performing the change in a load balanced environment, you may need to restart the other servers once you do the changes. I reset the DataFactory cache, but I am not sure it propagates through to other servers.

Yet a full fledged registration doesn’t seem like a proper thing to do – cluttering your EPiServer user repository with (let’s face it – for a large part fake or temporary email addresses that user create only to get your content).

While there may be a lot of ways to handle that (streaming it through a page Response.WriteFile might seem as one of the more obvious ones), I would like to show you a cleaner, simpler and more elegant way that I’ve come up with.

We really don’t want people to deep link to our files without them knowing the files are from our site, that’s just rude – so hiding them behind an obscure URL wouldn’t work (thus we cannot use the regular file providers). We’ve already establish that we don’t want to log them in, so setting file rights are useless. But I want all the benefits including client-side caching.

Basically the solution boils down to creating a thin layer over the File provider of our choice, in my case the versioning file provider. The only method we need to override in it is GetFile. I want to allow downloading for logged in users and I want to allow downloading for all users that have a “magic-cookie” set. If either of the conditions are met, the file just downloads using the underlying provider’s routines including all the logic EPiServer has put for caching and rights. But if neither of the requirements are met, the user is directed to a page of our choice.

public override VirtualFile GetFile(string virtualPath)
{
    string handledPath;

    if (TryGetHandledAbsolutePath(virtualPath, out handledPath))
    {
        if ((HttpContext.Current.Profile != null && !HttpContext.Current.Profile.IsAnonymous) ||
            HttpContext.Current.Request.Cookies.AllKeys.Contains(PASS_COOKIE_NAME))
        {
            return base.GetFile(virtualPath);
        }

        HttpContext.Current.Response.Redirect(
            string.Format(registrationFormUrl,HttpContext.Current.Server.HtmlEncode(virtualPath)));
        return null;
    }
    return Previous.GetFile(virtualPath);
}

How you specify that page’s totally up to you, but there is a nice initialization routine called during the Virtual Path Provider loading phase where all of the settings that are specified in your relevant web.config VPP declaration are passed to you, why not use it? What you’ll need define your VPP in the web.config is what follows:

<add showInFileManager="true" virtualName="CookieEnabled" virtualPath="~/CookieEnabled/" 
     bypassAccessCheck="false" name="CookieEnabled" 
     type="Cognifide.EPiServer.CookieEnabledVirtualPathProvider.CookieEnabledVirtualPathProvider,Cognifide.EPiServer.CookieEnabledVirtualPathProvider" 
     indexingServiceCatalog="Web" physicalPath="C:\vpp\Resources" 
     RegistrationFormUrl="/File-Asset-Request-Form/?filepath={0}" />

you can then define your class as:

public class CookieEnabledVirtualPathProvider : VirtualPathVersioningProvider
{
    private const string REGISTRATION_FORM_URL_WEB_CONFIG_PARAM_NAME = "RegistrationFormUrl";
    public const string PASS_COOKIE_NAME = "ResourcePass";
    private string registrationFormUrl;

    public CookieEnabledVirtualPathProvider(string name, NameValueCollection configParameters) :
        base(name, configParameters)
    {
        registrationFormUrl = configParameters[REGISTRATION_FORM_URL_WEB_CONFIG_PARAM_NAME];
    }

    ...

}

So we know now where we want to direct people without a “magic-cookie” who want to get our assets, and how to do it, but how do we finally allow that file to get down to them?

In your page – for the same of simplicity I assume you will be using XForms for gathering the user data, but that really does not matter. When you validate the form data (or get the user to click on a link that you’ve sent them) you just set the “magic” cookie that I called “ResourcePass” to any value and to to expire in some a long amount of time, like a year. So that they can now access your files unrestrained and direct them BACK at the URL they came from – and now the VPP will allow them to just download the file they initially requested:

protected void XForm_BeforeSubmitPostedData(object sender, SaveFormDataEventArgs e)
{
    if (!Page.IsValid)
    {
        e.CancelSubmit = true;
    }
    else
    {
        string requestedFile = Request.Params["filepath"];
        HttpCookie cookie = new HttpCookie(CookieEnabledVirtualPathProvider.PASS_COOKIE_NAME, "true");
        cookie.Expires = DateTime.Now.AddYears(1);
        cookie.HttpOnly = true;
        Response.Cookies.Add(cookie);
        if (!string.IsNullOrEmpty(requestedFile))
        {
            Response.Redirect(requestedFile);
        }
    }
}

Well, not really. By default the framework will be run in the “legacy mode”. Thanks to an old article by our own Marek Blotny, I’ve learned how to build Plugin settings which are just perfect for the purpose!

So to configure and enable the new features you need to open your admin UI and in the “Config” click on the “Plugin Manager” item and select our framework plugin as shown in the picture

The available options are:

Setting Name	Meaning	Sample
Default WebParts Path Pattern	The pattern to be used when no pattern is defined for a page.	%inherit%
WebParts Path Patterns	The semicolon separated pairs of pattern;pattern name; This is the part you will want to customize most.	%template%|%pageid%%legacyregion%;Legacy regionalized;%template%|%pageid%;Legacy globalized;page|%pageid%|%region%;Page/region;pagetype|%pagetypeid%;Page Type
Cache WebParts in Memory	Determines whether the WebParts are to be cached  between usages (this is useful for a small set of WebParts (like a number of sidebars) but rather discouraged if you use the legacy mode as there can be a lot of those in such case.	unchecked by default (check to improve performance in sidebar mode)
Legacy WebParts Support (per-page only)	If checked, disables the extensions described by this blog.	checked by default (uncheck to enable the sidebar extensions)

As shown here:

Once you fill in the settings as they are suggested in the above table the context menu (or adjust to your needs) will show you the new options:

The new sub menu will allow you to change the pattern by which the WebParts are selected, while “Edit Web Parts” option will enable you to edit the WebParts for the current effective WebPart set.

First of all – if you want to select a pattern on a page you need a means of storing it. At this moment The framework does it in a property. Which means – for every page type that wants to redefine the web parts rather than using the default pattern (in our case %inherited%) you need to add String property with a “WebPartsPath” name (I may actually add some routines to add the property definition automatically if there will be enough demand for that).

What does “Effective WebPart Set” mean?

Assuming (which is the most interesting scenario) that %inherit% is the default pattern the following is true:

Once you select the effective web parts for the page or just agree with the WebParts pre-selected for you based on the default path you can edit them just like previously. Mind that when you edit WebParts on a page all the pages that have the same “effective path” are going to change as well. (which was our intention in the first place).

The library extension is going to be posted on Epicode as soon as I get a hold of Steve to approve the changes :)

Hmm…

Is sidebar a part of content? No, rather not. We don’t want the editors to have to setup the sidebar for every article they write (and the site has a few dozens of articles created on it every day).

Is sidebar more of a template thing? Well… more like it, but still… we have articles all over the site with different sidebar elements when the articles are in different parts of the site (ok so we could add rules what controls display in which part of the site). But wait! There’s more! The sidebar will be different for every language (region). Now we’re talking a dozen of templates or a rules engine just to make the sidebar different. Customising the template with properties isn’t ideal either as it makes EPiServer UI very cluttered. Additionally we want to change sidebars across many templates so the whole branch/section of the site will be able to share the same sidebar.

To a degree this is an academic discussion as we’ve been through it with the previous version of the site and we already knew that integrating this stuff into templates just won’t work and we will be in a world of pain just changing the templates over and over adding little tweaks and changes while the customer ads promotions and performs ad campaigns. Well, we can do it, of course, but it’s not a work a programmer will enjoy, and we all want to do new and more exciting things, don’t we?

We have an internally developed  module to make something like that, that is fully home-grown by another internal team (we now have 3 “squads” capable or making incredible things with EPiServer and we tend to share a lot of technologies and try to rotate people around to adopt the good habits and experiences) and I was (and still am) VERY impressed by it. The technology uses EPiServer pages for defining every module (which are located somewhere outside the site root branch. and then you can mix and match them either declaratively in the code) or by handpicking them in the UI. It’s really cool, though, during the discussions it turned out that we might have to add big chunks of functionality and might end up with separate branches of module-pages for different languages/regions, but… frankly… about that time an article by Ted Nyberg reminded me about a technology I have read about quite a while ago in an article by Stein-Viggo Grenersen and ooohhhhhh… I got seduced. I really wanted to try if for a long time and Ted’s article made it a snap to try and get convinced, and more important… convince Stu ;) that it’s the right way to explore.

So I started to dig.

Talked with Steve (the original creator of the Framework) a bit and learned that I can “customize a path rewriter” to suit my needs. Great! I just hoped I won’t have to deal with some nasty GUID’s matching, but no! Turns out, all it takes to identify a WebPart set is to have any unique string naming it.

So basically what we needed was a manager to deal with the naming templates and a way to determine the WebParts set to be used per page.

Till now the framework used template file name followed by the page ID, followed by an eventual language/region if a page was not the master branch, for example:

~/templates/Demo/WebPartPage.aspx|26
~/templates/Demo/WebPartPage.aspx|26|en-us

which makes them unique per page, which is not as appealing when you use EPiServer as it for a big part duplicates its functionality. Also a bit of a caveat here for agile programming methodology which promotes an often and early refactoring – if you move your page around or change its name – you lose the WebParts for all pages using it.

What we needed is a flexible and extensible scheme for reusing “WebParts sets” and that’s what our extension allows for.

Also since we’re very performance sensitive, and we operate in a multi server scenarios a lot we’ve added web parts blobs caching. Meaning that the site does not have to reach to the database every time a page is rendered.

The very appealing side of the framework is that it can be extended form the bottom (persistence) from the top (editors, controls, webparts), as well as being pluggable with custom plumbing.

The Sidebar Extensions for WebParts Framework

So to put all the requirements together, we needed the sidebars to be:

• customizable (out of the box)
• easy to use for both developers and editors (out of the box) Wow Steve, I can’t really appreciate enough how cool it is to code for it and how nice it is for the users!
• localizable
• reusable
• inheritable for site branches

WebParts path patterns

The main idea was to free the path names from the restriction they had – being hardcoded for a page. So to do it without hard-coding them I’ve introduced path patterns.

What is a pattern?

Basically a pattern is a way the framework is supposed to encode the WebParts  id for the system to identify. Your site can have any number of “named patterns” and the framework gives you means of switching between them. Pattern allow for almost any string to be a part of it although some tokens have special meaning:

Some sample patterns

The use case is as follows:

• The client wants the site to look exactly as in a template provided as a image,
• the text is using a non standard font that is not available on 60% of Windows machines,
• the site does not use flash.
• the site needs to be equally good looking in IE6 (more about it later)

The solution was to generate images, but how to do it the right way? This has presented us with a once-in-a-lifetime :) opportunity to create a virtual path provider, do something good and learn something new & cool in the process.

Creating a new virtual path provider.

this functionality in itself is fairly well documented on MSDN one thing to pay attention to is to remember to pass the control to the next provider in the provider queue if your provider does not want to serve the request, so in my case:

        public override VirtualFile GetFile(string virtualPath)
        {
            if (IsPathVirtual(virtualPath))
                VirtualFile file = new TextImageVirtualFile(this, virtualPath);
                return file;
            else
                return Previous.GetFile(virtualPath);
        }

this is necessary so you don’t have to have all-or nothing solution (your provider either serving everything the user requests or not being accessible at all) and honestly I’ve spent quite a while before I found out that… I was just being silly – thinking the technology by itself will resolve that ;)

If your Virtual path provider does not actually implement directories you don’t have to make the very provider to do a lot of complicated things. you are perfectly fine to limit the implementation to providing a custom constructor so that EPiServer passes you the configuration data and a couple of methods to tell whether a file is what you want to handle or not

// this one is actually really cool - whatever values you set in your web.config 
// will be passed to you in the collection so you can really make your VPP 
// as configurable as necessary
public TextImageVirtualPathProvider(string name, NameValueCollection configAttributes)

// This one resolves if the file can be generated
public override bool FileExists(string virtualPath) { /* ... */ }

// Pretty much only passes the info that directory was not found 
// found if the virtual path matches a path that we should handle
public override bool DirectoryExists(string virtualDir) {  /* ... */  }

// Retrieves the virtual file that generates the image if the
// Virtual path matches our pattern or disregards the request if it doesn't
public override VirtualFile GetFile(string virtualPath) {  /* ... */  }

// Again this is only a pass through method as we don't support directories
public override VirtualDirectory GetDirectory(string virtualDir) {  /* ... */ }

Now that we have ASP passing the request to us we need to wonder how to format the request in a way that is intuitive to the user, I wanted the URL to be straightforward and follow the path of EPiServer’s friendly URL-S so that they are easily formed by editors. So how about:

http://my.server.com/color/font-name/font-size/The%20text%20i%20want%20to%20print.gif

Ok.. well…, that won’t fly for GIFs – the font will be plain ugly if I don’t use antialiasing and if I do I will have an ugly black background underneath it. The solution to that would be using translucent PNG (which the VPP supports) but IE6 does not support those with transparency without ugly hacks. So I need to replace the blacks with a hint so that it generates a background colour when it merges the background with the font for antialiasing. For the sake of this article let’s assume it was an easy switch (IT WASN’T!) and let’s extend the URL to:

http://my.server.com/color/antialias-hint-color/font-name/font-size/The%20text%20i%20want%20to%20print.gif

But I need the font to be bold! Ok… ok…

http://my.server.com/color/antialias-hint-color/font-name/font-size/font-formatting/The%20text%20i%20want%20to%20print.gif

Can I have the image rotated too? Sigh….

http://my.server.com/color/antialias-hint-color/font-name/font-size/font-formatting(optional)/transformatio(optional)/The%20text%20i%20want%20to%20print.gif

The image rotation follows the RotateFlipType enumeration so you can specify any string that is defined in the MSDN documentation for the enumeration.

A sample result for the URL:

http://my.server.com/TextImages/Blue/white/Courier%20New/40/BUI/rotate270flipnone/Hello$eol$from$eol$Cognifide!.gif

Will look as follows

For the curious

The final string format matching regular expression looks as follows:

Regex regex = new Regex(
    @"^(?<colour>                  # The first match - starting form the beginning of the string
    ([0-9a-fA-F]{3}|[0-9a-fA-F]{6}|[a-zA-Z]*))   # match either a 6 hex digit string or a name of a known color - this is for text color
    /                             # now we expect the first separating slash
    (?<hint>                      # next match group is about background hint for antialiasing
    ([0-9a-fA-F]{3}|[0-9a-fA-F]{6}|[a-zA-Z]*))   # match either a 3 or 6 hex digit string or a name of a known color - this is for antialiasing color hint
    /                             # again separating slash
    (?<font>[\w\s]*)              # font family name - accept white spaces
    /                             # yet another separating slash
    (?<size>[\d]{0,3})            # font size 
    /                             # oh noes! another slash!
    ((?<style>[BIUSRN\s]*)        # font style Bold, Italic, Underline, Strikethrough
    /){0,1}                       # this group is optional.
    ((?<transform>[\w]*)          # transformation name as specified with System.Drawing.RotateFlipType - this group is optional
    /){0,1}                       # this group is optional too.
    (?<text>[\s\S]*[^\.])         # the text to render - basically anything but a dot - use relacement strings for dots
    [\.]                          # separating dot - now that's a nice change!
    (?<extension>(png|gif))       # the file extension - so that we know whether to generate png or gif
    $                             # everything comes to an end  
    ",
    RegexOptions.Compiled | RegexOptions.IgnoreCase | RegexOptions.IgnorePatternWhitespace | RegexOptions.CultureInvariant);

Usability concerns

The Colours can be provided as both named Colours (red, green, etc..) or html hex formatted colours (e.g. ff00bb, fob, fff, badfoo) both 6 and 3 hex digits strings are accepted.

The URL accepts spaces, and whatever text string that cannot be passed as a part of the url or is invalidated by EPiServer can be escaped by defining a token for it in web.config so for example as you can see in the above url the end of line “\n” character has been escaped into $eol$.

Obviously the font selection is limited to what is installed on your server.

Performance concerns

The basic concern that comes to mind is – how does this impact the server performance if the image is generated every time? Even though the performance impact seemed to be negligible I’ve decided to cache content. These things simply pile up if you have a high load site so why take the chance? Once an URL is called it is saved on first generation asserting the uniqueness of each parameter. Colours like black and 000 will be treated as same colour and cached only once.

Security concerns

So what was done to prevent our server to be an open server for generating images for everyone on the Internet? The VPP only allows for the images to be generated if the request referrer is in a domain or a host that is specified in the web.config. Additionally for testing you can enable the referrer to be null (direct call to images, as opposed to referring to them from a page).

Also as a seconds line of defence, it’s wise to define the cache folder on a share with a quota so we don’t get our server filled up with images should the referrer limiting measure fail for some reason.

So how is the faceted engine structured?

Content provider

As you can see the driving force behind the engine is the Facet Tagged Content Provider. If you know EPiServer, the basic functionality of the module is roughly an an equivalent of find page with criteria for categories, which allows for searching pages tagged with facets with exclusion of some other facets and tagged some optional data, the module however is paging and and allows you to plug a feedback event handler so that your controls can accept or deny a story before they are sent to is and take part in the paging. The stories are provided to you in reverse order of publishing so you always get the latest stories first, (pretty much what any blog and any news site wants).

Another function of the content provider is assertion of story uniqueness on the page. This is actually a pretty cool mechanism that deserves closer attention.

Let’s imagine a page having a control with “main story” that is pre-selected by an editor, and then some “featured stories” also pre-selected, then there is a control with “latest news concerning facet A” and a “latest news concerning facet B”. The problem with this scenario is that if a story was pre-selected for the “main story” and perhaps then someone added it to “featured stories”, and the story actually is tagged by facet A and facet B – in a traditional search you would normally get it in all of the controls… not cool!

The solution that we’ve come up with is based on a free market rules. And the procedure is as follows:

1. The request starts and the engine opens a bidding for articles.
2. All the controls request their interest in stories by either providing the engine with pre-selected stories they would like to display or asking it to provide the freshest content based on the facets the content is tagged with. They also provide it with their value (priority). And a callback for the engine to provide them with the stories.
3. The acceptance phase ends and the engine distributes the stories looking from the highest value controls down the list in the following way
   • when the control provide the list of articles if so check for each article if it has not been taken yet, and otherwise feed it back to the control
   • otherwise if the control provided it with the facets it’s “interested in” it asks the tagged content store for articles tagged with this context and feeds them to the control if they have not been otherwise provided to another control with higher priority, until it reaches the number requested by the control. (this way of providing articles also allows for paging).
4. Upon satisfying all the controls the bidding is closed and all articles become available again.

Content Accelerator

Content accelerator is a caching module that we have made mandatory that all of our EPiServer calls must pass through. The engine turns the pages into objects with a well defined and hard typed objects rather than a-bag-of-strings-and-the-likes your usual PageData is.

This makes it much more efficient for us to cache only the important data contained in any given page and only the data that we use frequently, e.g. page name and page URL that are used by URL provider and that are likely to be called multiple times within any given user request. This has been been implemented to compensate for the slowness of GetPage calls.

For that to work effectively we always tread content accelerator as a proxy for GetPage – which allows us to filter any expired or not yet published pages faster and refresh the content and accessibility for everyone, any time any given content is refreshed.

The For this concept to work – any page type that is going to be used in it has to have its own class added to it with the properties you will usually access (this however should be done with caution, for example you can cache article intro, but caching a potentially big article is a bad idea – also a full article text is very unlikely to be displayed on a high traffic page so caching all of your article full texts will not offset for a potential quick running out of memory).

Also the content cache is written using generics in a way that allows you to specify a multiple classes for any page types – the class consuming the cache defines how it wants to treat the content and access it. The different cache classes will then be chain linked and refreshed.

The content expires on an arbitrary set time (1 minute in our case but you can specify any other period), but we’ve also written a web service allowing for expiring a page-cache-item whenever it is changed on any of servers in a multiserver scenario. This for this to work – you have to plug into the global EPiServer event handlers. Which I’ll describe later.

The accelerator is used extensively by the faceted engine, but it can also be used directly and is completely independent of the rest of the faceted engine.

Facet Context Provider

This provides the control with ewasy facility to retrieve the facets with which the request was performed.

Facet URL Provider

This service allows you to construct URLs based on a facet context – with automatic determination of a preferred visualisation (hub page). Naturally you can still force the provider to format the URL for a pre-determined page. The effect will be a request that can later be succesfully parsed by the Context Provider once that URL is executed on the server.

Auto Tagging Module

This block which originally was a separate module is now basically shrunk to a single method that you can plug into EPiServer in the Global.asax. The routine tags a page with facets predefined in its parent, during the process of a page creation. This is useful for tagging e.g. all the “technology” stories with “technology” facet and an “News” facet once its created in the “Technology articles” branch.

Furniture

Part of the faceted navigation, but not directly part of the engine are editors for facet roles, the very facets and facet selectors.

First of all we have to explain the nomenclature as it is going to be used quite a bit. A few terms we use pretty extensively are:

• Facet – this is roughly an elaborate version of an EPiServer (or Wordpress) category. One of the problem with EPiServer category is that it is just that and absolutely nothing more. There is no way for attaching metadata and conditional structuring of the category tree. There is no way to assign them roles. Facets provide you with much, MUCH more.