Episerver’s Custom Page Providers

By Deane Barker • February 20, 2009 • 2 min read •

Author Description

Discussion of an example of content aggregation, or the ability to raw in content from disparate sources and present it as part of a unified system.

AI Summary

This post explores custom page providers in Episerver, detailing how they enhance content management flexibility. The author discusses implementation examples, offering insights into best practices and potential challenges developers may face while integrating these providers into their projects.

Blend has been working with Episerver lately. It’s a commercial .Net content management system based out of Sweden.

We flew out one of their trainers from Denmark back in November – an awfully entertaining guy named Allan – and determined that he, and he alone, has the coolest job ever. His job description is essentially to write cool stuff with Episerver. Like, all day.

He was showing us a neat feature of the system which I’ve become enamored with: custom page providers.

Episerver organizes its content into my beloved content tree (with subcontent, even – yippee!). Each content item is considered a “page.” You create a page, then subpages underneath it, etc.

With custom page providers, however, you can “hijack” part of the content tree, and write code that returns subpages from some other source. So, when Episerver opens that part of the content tree, it’s actually not retrieving pages from its own repository. Instead, it’s getting them from wherever you tell it.

The best analogy I can give is that Episerver lets you “mount” a different content repository at any point in the content tree, like mounting a Unix file system.

Allan gave me the screencap pictured here, in which he’s mounted a folder from the underlying Windows installation as a branch of the content tree. When you open the “File” page, the subpages are just files on the file system. To do this, he wrote a simple translation class which Episerver invokes and that queries the file system and returns the results as pages.

This can even be read/write. You can actually tell Episerver how to update the external datasource, so – in this case – by saving “pages” in the admin interface, you’re actually writing files back to the file system.

The implications here are pretty cool from a data integration perspective. A few ideas:

If you have a product catalog, you could return records from it under a “Products” node. In this way, your catalog can power a small part of your CMS, in real-time, without editors ever knowing they’re slipping into and out of Episerver’s true content repository at this point in the tree.
For an intranet, you could provide “pages” from Active Directory (note the “AD” node in the screencap – I’m quite Allan has done just this…). An “Employees” page could return OUs as subpages, and actual AD user records under that. The presentation layer would never have been the wiser that this information didn’t live in Episerver.
You could even use a Web service to grab pages from an internal wiki (or from Wikipedia, for that matter). Mount all the pages under a particular category as subpages.

The potential is endless. I find it particularly interesting for intranet scenarios which tend to have to draw content in from multiple places. With custom page providers, you can aggregate content from all over while presenting a consistent administrative interface to your editors and having technical consistency in your presentation layer.