Routing a Specific Page Request to a Specific Controller

I’ve always appreciated EPiServer’s ability to be friendly to arbitrary code – if you have some application-ish functionality you need as part of your site, EPiServer will play nice with it without you having to jump through hoops.

However, it’s really helpful to be able to “wrap” this code in a page, so that it can be part of the page tree.  Even apps running inside your site need crumbtrails, navigation, permissions, etc.  EPiServer has to know about them and know where they “live” in the page tree so that it can manage all the things around them.  Consider that the average master page or layout requires knowledge of the CurrentPage in dozens of different ways to render properly.

I blogged about this several years ago: Using Proxy Content Objects for Non-CMS Content. That blog post is worth reading as it explains the problem and solution, which is universally valid for every CMS.

Sometime after that, I built a simple plugin for EPiServer (webforms) that allowed you to direct specific page requests to specific templates, which I blogged about here: Selectively Overriding Page Type Template Mapping. This plugin used RewritePath to rewrite the inbound request to go to the webform of your choice.

I’ve now done the same thing for MVC, except using a custom controller rather than a custom webform. On your page type, you can have a property that indicates what controller you want to use for that specific page (named "CustomController," by default). Inbound requests to that page will get redirected to that controller.

You can use this to build an application that has its own controller and views, and then "wrap" that application in a page by creating a page and redirecting it to your controller. (Yes, you could do this by creating a new page type with that controller and a renderer, but creating one-off page types just to do that is messy.)

For instance, say you build an application to view your log files. Then create a page, and specify "Log" as the custom controller for it (the suffix "Controller" is automatically added). Now, all requests for that page -- no matter where in the page tree it lives -- will get routed through LogController.

(Clearly, you need some security around this property. It needs to be on a secure tab, or have some other method to ensure the average editor doesn't do something silly. Either that, or change the logic to some other method than a user-entered value. I leave that problem to you to solve...)

The code is straightforward -- just compile it in. If your page doesn't have the "CustomController" property or if it doesn't have a value, the request will pass right through.

It’s well-commented, so it should be easy to modify, and it’s also a good example of both an InitializableModule and how to hook the template resolution engine.

Update:  I added a way to specify the Action as well by using a slash between controller and action name.  So, a value of “Log” will send the request to the “index” action of the “LogController.”  However, a property value of “Log/Display” will send the request to the “Display” action of the “LogController.”

Download CustomControllerResolver.cs