Normal “templates” with ASP.Net web forms uses the App_Themes folder and then places skin and css files so that different templates can be used. The problem with this, as I outlined in the introduction, if you set up a master page, there isn’t much you can do to change the complete layout of the site unless you modify that master page. When you have to maintain a single code base for an entire project, modifying this per customer is virtually impossible.

A solution to this problem is to move that master page out somewhere that a web designer can easily change but not have it affect the main site. For this part, there are a few simple steps:

Create a folder for the templates

Create a configuration setting for a current template

Create a base page that will set the proper template

First we will create a folder to store the templates and move our master page there. Keep in mind that this can be pretty flexible. You can have multiple master pages. To keep this simple, however we are just going to use one.

You cannot use the App_Themes folder as you are not allowed to put a master page in there. Also, my recommendation for these master pages is to not have any code behind files. Keep it simple and only have the page.Master and nothing else. Code can be added to the markup if needed and in the next part of this series, I will outline how to build out a template API so that designers can get to your site functionality pretty easy. For now, just keep in mind that once you get rid of the code behind file, you will need to create a base master page class that these master pages inherit from. See below:

Once the folder for the templates have been added (I called it Themes), create another folder called Default and move your master page there. This will be our default theme. You should also place any CSS and image files into this default folder. Feel free to organize, but make sure you update the paths to these files. If you happen to need to use any of the images within your main content pages, make sure to set a standard (and document it) path. That way every template has the same path to the image files. It’s also a good idea to standardize the names of these files unless you build out a a full template setup where there is a theme settings file that specifies which image is for what component of the site. Additionally, get rid of any code behind. If you already have a complicated master page that has lots of code behind (like I dealt with) you will need to start on an API to bring the functionality you need back to the page.

Just so that we can see success when we are done, create a second template folder and make a copy of your master, css, and images into this folder. Change the master page in this template so that you will know it’s using a different master page when we switch templates.

For the next step, we need to set up a configuration of some sort so that the template can be switched. Ideally this will include a admin page to change the template. For now, we will just create a simple settings class that will hold our current template setting. Then we have this class save and load our settings. See below:

Now the final step is where the magic happens. To make things easy, so we don’t have to add code in each of our pages, we will make a base class that each of our pages will inherit from. This is the place where we will be setting the master page to use. This is pretty easy to do. See below:

If all goes well you should be able to run the site and be presented with your default template. Now, to see the magic happen, change the settings.xml file to reflect the other template you set up and rerun the application.

I maintain a fairly simple CMS that our customers use for their public facing web site. Most of the CMS is pretty straight forward. Create, publish, edit content, etc. I took over this project as it was originally designed by an outside contractor. For the most part, the meat of the application is the same, aside from some changes here and there to optimize code reuse, optimize performance, add features, etc.

Since this CMS was designed to be installed as public facing sites, it was built to have templates so that each site could maintain their own unique look and feel. This was done in a pretty standard way that most ASP.Net sites are created. The site is created with a master page that helps maintain the same look and feel through the whole site and then in the App_Themes folder, the CSS files change the way the site looks. Code was added so that the theme can be switched on the fly.

This worked excellent for many years, however recently we had been getting many requests on completely changing the layout and placing content in places that were not designed to have content. Others wanted their main content to look much different than what we could support.

So, I set out to devise a way of doing templates that would allow the web designer complete control over the site templates. This small series is going to show (in a simplified way, mind you) how I built the new templates to give the web designer more control over the overall design of the site.

As I add posts to the series, I will add them to the bottom of this post.