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:

1. Create a folder for the templates
2. Create a configuration setting for a current template
3. 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:

namespace ASPNetTemplates.CMS
{
  public class BaseMasterPage : System.Web.UI.MasterPage
  {
  }
}

And in the master page:

<%@ Master Language="C#" AutoEventWireup="true" Inherits="ASPNetTemplates.CMS.BaseMasterPage" %>

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:

Settings.cs –

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Xml.Serialization;
using System.Xml;

namespace ASPNetTemplates.CMS.SiteSettings
{
  public class Settings
  {
    public string CurrentTemplate { get; set; }

    public static Settings CurrentSettings
    {
      get
      {
        Settings siteSettings = LoadSettings();
        if (siteSettings == null)
          siteSettings = new Settings();

        return (siteSettings);
      }
    }

    public static Settings LoadSettings()
    {
      Settings siteSettings = null;

      using (var file = System.IO.File.Open(string.Format("{0}{1}//{2}", HttpContext.Current.Request.PhysicalApplicationPath, "App_Data", "Settings.xml"), System.IO.FileMode.OpenOrCreate))
      {
        var xmlSer = new XmlSerializer(typeof(Settings));
        try
        {
          siteSettings = (Settings)xmlSer.Deserialize(file);
        }
        catch (InvalidOperationException)
        {
          // An invalid operation exception is thrown if the settings.xml file doesn't exist or is blank.
        }
      }

      return (siteSettings);
    }

    public static void SaveSettings(Settings siteSettings)
    {
      using (var file = System.IO.File.Open(string.Format("{0}{1}//{2}", HttpContext.Current.Request.PhysicalApplicationPath, "App_Data", "Settings.xml"), System.IO.FileMode.OpenOrCreate))
      {
        var xmlSer = new XmlSerializer(typeof(Settings));
        xmlSer.Serialize(file, siteSettings);
      }
    }
  }
}

Settings.xml -

  Default

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:

namespace ASPNetTemplates.CMS
{
  public class BasePage : System.Web.UI.Page
  {
    protected override void OnPreInit(EventArgs e)
    {
      base.OnPreInit(e);

      this.MasterPageFile = string.Format("\\Themes\\{0}\\Site.Master", CMS.SiteSettings.Settings.CurrentSettings.CurrentTemplate);
    }
  }
}

Then in our pages we just inherit from this class -

namespace ASPNetTemplates
{
  public partial class _Default : CMS.BasePage
  {
    protected void Page_Load(object sender, EventArgs e)
    {
    }
  }
}

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.

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.

ASP.Net Web Forms Templates – Part 1

The way most people seem to have done session state (at least in just random searches on the internet and in sample code), you see this:

  HttpContext.Current.Session["SomeData"] = myData;

There is nothing wrong with this. It works. Is it maintainable? Sort. Is it a potential problem? YES! What happens if you do this somewhere:

  myData = HttpContext.Current.Session["SomData"];

Obviously you are going to get a null object back and possibly an error depending on other factors. You will probably find the problem during your automated tests (you do have automated tests right?) or at minimum find it during your own testing. The problem is, sometimes things like this will slip past if they are in infrequently used parts of a system that no one bothers to check for 3 or 4 versions that pass.

So in searching around I found various posts on how to wrap your session state into a more manageable object so that typos don’t creep up and bite you on the backside. Some of the examples went way over what I needed to do and some were way too simple to make sense for me.

So here is what I did (if I happened to have stolen your code, sorry, but it happens in software).

First I created my Current Session class to store everything and I made it static since Session itself is a static object.

  public static class CurrentSession
  {
    private static HttpSessionState LiveSession
    {
      get { return HttpContext.Current.Session; }
    }
  }

This simple gives me a class that has access to the current session through a private variable called LiveSession.

Inside this class, I created another class for the CurrentUser since I needed to track the current logged in user (this user has data from the web service, so I’m not using asp.net authentication methods).

    public static class CurrentUser
    {
      public static bool IsLoggedIn
      {
        get
        {
          bool? logIn = GetUserItem(UserData.LoginState);
          if (!logIn.HasValue) logIn = false;
          return (logIn.Value);
        }
        set { SetUserItem(UserData.LoginState, value); }
      }

      public static FamilyData CurrentFamily
      {
        get { return (GetUserItem(UserData.Family)); }
        set { SetUserItem(UserData.FamilyInfo, value); }
      }

      private static T GetUserItem(UserData key)
      {
        T data = (T)LiveSession[Enum.GetName(typeof(UserData), key)];
        return (data);
      }

      private static void SetUserItem(UserData key, T data)
      {
        if (data == null)
          LiveSession.Remove(Enum.GetName(typeof(UserData), key));
        else
          LiveSession[Enum.GetName(typeof(UserData), key)] = data;
      }

      public enum UserData
      {
        Family,
        LoginState
      }
    }

Now, some explanation and why I did it the way I did. I could have just made my public variable have the getter and setter access the Session object directly. My typo chances would have been minimized by the fact that it’s only in two spots that I need to type it, but there is still a chance. So I created myself an enum that I can use to specify which sets of data I am saving or retrieving. I use the enum’s string value as the session object name, so all I have to do is make sure my enums never use the same name. In my RLC (Real Life Code) I use much longer enums, like CalendarFilterMonth or CalendarFilterDay, for example. In the above example, I use LoggedInUserFamily in place of just Family. While it may be long, intellisense always gets it right for me with just a few keystrokes.

The GetUserItem and SetUserItem simple save and retrieve from the LiveSession object. I use Type generics to tell the functions what type I am saving and retrieving for ease of use. My type casting never has to be done now. I tell it what I want and that’s what I will get in return.

The best part about this, is to add more, all I need to do is copy and paste a property and change a few of the options, maybe add an enum, and now I’m done. I don’t have to worry about typo’s and I can organize my session object however I want.

To use it, I just do this anywhere in my application:

  if (!CurrentSession.CurrentUser.IsLoggedIn)
     RedirectToLogin();
  else
     if (CurrentSession.CurrentUser.CurrentFamily.NeedsProfileUpdate)
        RedirectToUpdate();

Since NeedsProfileUpdate is part of my FamilyData class, I can access that directly!

After doing some searching, I found a few examples of using WCF and implementing custom username authentication, which is exactly what I wanted to do.

Getting WCF set up and running was quite easy. Porting over our web service code just meant creating my ServiceContract and DataContracts and then recompiling. I also had to set my SQL to Linq datacontext serialization mode to Unidirectional. After coding up my custom username authentication and testing it, things were going along quite smoothly.

Everything I had experienced with Linq to SQL serialization still applied to WCF. Relationships had to have the parent set to internal access instead of public. I did also find that the relationships seemed to need a One-To-Many in order to work right. If it was a Many-To-One or a Many-To-Many, it wasn’t being sent from the WCF service to the client. Since I was in a hurry, I left that issue on the back burner and worked around it. If I five more into it, I will post about it here.

The one thing I had not counted on, was the fact that if you have any fields (properties) marked as being nullable, the Add Service wizard in Visual Studio 2008 will also add a boolean field called fieldSpecified. So if you have a nullable field for, say, PhoneNumber, you will have that and PhoneNumberSpecified. If you fill in the PhoneNumber field, but do not set PhoneNumberSpecified to true, the field will not be sent to the WCF service.

From my little bit of research, if that Specified field is set to false, the property will not be included in the XML document sent to the WCF service. If it is set to true, it will send it whether it’s null or not.

Since some of our classes have quite a few fields and we have quite a bit of code to set those fields, I did not want to go through and set every one of these stupid properties to true when I set a field. I’m actually quite surprised that we even need to do this.

In searching for an answer, I found the long way around of writing a program to parse your service.cs (or .vb) file and inserting this code:

  [System.Xml.Serialization.XmlElementAttribute(Order = 0)]
  public string PhoneNumber
  {
    get
    {
      return this.PhoneNumber;
    }
    set
    {
      this.PhoneNumber = value;
      PhoneNumberSpecified = true; // Line Added
    }
  }

So, we have to add one line to each property that has a corresponding Specified field. Now I know why people wrote a utility to do this. That file will get overwritten each time you update your service reference.

I wasn’t too pleased I had to do this so I tried to find a better way. I finally settled on using the PropertyChanged events and some reflection to go and fill that field in.

To make things simple, my Linq to SQL classes all have a base class called BaseBusiness where I do validation and hold some original values so we can use the disconnected nature of the web with Linq to SQL entities. Since I did this, I can only derive my classes on the client side from the same base class. So I created my BaseBusiness class and included my PropertyChange event in there like this:

  public partial class BaseBusiness
  {
    public void InternalPropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
    {
      if (!e.PropertyName.Contains("Specified"))
      {
        string prop = String.Format("{0}Specified", e.PropertyName);
        PropertyInfo target = this.GetType().GetProperty(prop);
        if (target != null)
        {
          PropertyInfo src = this.GetType().GetProperty(e.PropertyName);
          bool currentValue = (bool)target.GetValue(sender, null);
          bool hasValue = (src.GetValue(sender, null) == null ? false : true);
          if (currentValue != hasValue)
            target.SetValue(sender, hasValue, null);
        }
      }
    }
  }

This is pretty straight forward so far. I check to see if the field is already set to what it should be so I don’t make any unneccesary calls. Note that I use sender as the object I am using the GetValue and SetValue on. This is because the event is in a base class and wouldn’t be the right object to use for reflection since the properties would be one level up (or down, depending of where you stand).

Now the only step left is to write it up in the data classes. Which is nothing more than this:

public partial class MyDataClass : BaseBusiness
{
  public MyDataClass()
  {
    this.PropertyChanged += InternalPropertyChanged;
  }

  ~MyDataClass()
  {
    this.PropertyChanged -= InternalPropertyChanged;
  }
}

So I fired up the excellent MemProfiler, I started digging into the issues. Aside from some of the other stupidity I was doing, I found a problem with a vendor’s component. We use Developers Express controls for EVERYTHING and we love them, not just the controls, but the company. When I found this issue with XtraReports not being GC’d after a dispose, I immediately created a small sample for them and submitted a ticket.

Less than 2 days later, they already have it fixed and ready to rock in the latest version. Not only am I impressed, but I am put at ease knowing that if a problem comes up, they are there to not only fix it, but fix it quickly and get it out to people.

This also happened a few months ago when their ASPxThemeDeployer wouldn’t work on my x64 Vista machine. I peeked at their code and saw why. Reported it and the VERY NEXT DAY they had a solution to the problem and pushed out an update.

I don’t have to worry. I know I am taken care of.

Thanks guys!

There are a couple of options.

1. Make the data context serialization unidirectional. This will turn off all relationships. You will have to manually do your joins using Linq when the data reaches the other side of the transaction.

2. Change the parent access modifier of the relationship to Friend (VB) or Internal (C#). This leaves the child relationships intact but removes the parent relationships. There would no longer be a family relationship in the person entity.

I prefer option 2 simply because then I don’t have to rejoin my data every time I fetch it. I don’t need those child to parent relationships because I can build around it by making my web service functions return the family instead of just returning a person, even if I just request the person.

The next issue that I ran into was the updating existing records. Since adding new records takes a detached object and just inserts it as new, that isn’t an issue. The problem comes in the concurrency tracking that Linq to SQL uses. You either time stamp your record, or you allow it to check previous fields for concurrency. We don’t use the time stamp method. The way that most things work in the SQL world is that when you save, you either overwrite what is currently in the table, or you get an concurrency error that makes you input everything over again after getting a refresh from the database. This is not the way we like it. We like a merge scenario where I can make a couple changes to the record and someone else can make some other changes and we the save is made, both our changes make it to the database.

So, how do you fix this? It’s easy with Linq to SQL. It already has the merge saving built in, unlike ADO.Net. (The Entity Framework will do this as well if you set it up right.) Even though Linq to SQL already supports the saving, this won’t work in web services. The problem is that during serialization, the entity loses it’s data context. It’s the data context that actually tracks the changes in the record, not the entity itself. So once the data context loses it’s entity (gets detached), it has to be reattached in order to do the save. The problem with this is that the data context no longer knows what has changed in this entity, so it cannot do any concurrency validation. The key is to use the Attach method and fill in two of it’s parameters, one for current entity and one for the original entity. There are a couple ways you can do this, but I choose to add a base class where I could store the serialized entity (complete with children) and ship it back and forth.

No matter how you slice it, you are going to have the overhead of change tracking eating up bandwidth to and from the web service to the calling application. This can either be incredibly apparent by holding your original values in the session state and just passing it back to the web service, or you can serialize it in the entity object and just pull it out later. I use this method for simplicity. I actually just make a business class (actually, I already had one because all my validation is stored there in a generic, fun sort of way that allows it to just interact with IDataError) and in that business class, I just add a object holder and some functions to set the original value.

Here is a small sample of the base business class:

Imports System.Xml.Serialization

Public Class BaseBusiness

  Private original As Object

  Public Sub SetOriginalValue(ByVal _OriginalValue As Object, ByVal originalType As System.Type)
    Dim sb As New StringBuilder()
    Using strw As New System.IO.StringWriter(sb)
      Dim SXO As New XmlSerializer(originalType)
      SXO.Serialize(strw, _OriginalValue)
      original = sb.ToString()
    End Using
  End Sub

  Public Function HasOriginalValue() As Boolean
    Dim bOriginal As Boolean = False
    If original IsNot Nothing Then
      bOriginal = True
    End If
    Return bOriginal
  End Function

  Public Function GetOriginalValue(ByVal originalType As System.Type) As Object
    If HasOriginalValue() Then
      Dim sXml As String = CStr(original)
      Dim fam As Object
      Using strr As New System.IO.StringReader(sXml)
        Dim SXO As New XmlSerializer(originalType)
        fam = SXO.Deserialize(strr)
        Return (fam)
      End Using
    Else
      Return (Nothing)
    End If
  End Function
End Class

Notice the use of System.Type, this allows me to pass in any data type and serialize it on the fly without having to have special code in my entity class. This makes it appropriate for any class I need to track changes in, even in the entity framework if I so desire.

Here is the top level entity class where I use it:

Imports System.Xml.Serialization

Partial Class Family
  Inherits BaseBusiness

  Private Sub OnLoaded()
    OriginalValue = Me
  End Sub

  Public Property OriginalValue() As Family
    Get
      Return CType((Me.GetOriginalValue(GetType(Family))), Family)
    End Get
    Set(ByVal value As Family)
      Me.SetOriginalValue(value, GetType(Family))
    End Set
  End Property
End Class

That is the only code that will need to be in the entity class in order for it to work. The best part of this is when the data gets shipped back and forth, it’s always accessible as the original entity, not a serialized XML string.

This was just a quick test I did when investigating this stuff today. Eventually, I am going to try to minimize the code in both classes some more and see if I can even strip out the XML Serialization to string and just store it as binary data.

I checked out ASP.Net MVC first because that seems to be all the rage right now. I can definitely see why people are excited. I had a fully functioning site up and running in no time. It’s definitely a great framework and introduces a lot of very nice features. I love the testability it introduces into the whole equation, even the view.

What I don’t like, is the fact that it doesn’t support 3rd party controls. With the exception of Telerik and possibly Infragistics, others are SOL right now until the component vendors get their components up to speed. I know Jeff Handley had posted a few articles about extending the base controls, but I’m talking about some serious controls, like Dev Express’s grids and asp editors. I know there are options, but we will never ditch Dev Express. They have been too good to us. When I can e-mail the CTO with an off the wall management question and have him respond within 8 hours, and submit a message to a general e-mail with some questions about their plans and get a phone call from them within 8 hours, that’s not only a company that makes a great product, but a company that cares (shameless plug for you guys Julian and Mehul).

So I started to investigate other options. When searching for some silverlight info, one of my dudes discovered Visual WebGui. Visual WebGui was pretty slick. You drag and drop onto what looks like a Windows Form and where you drop it is where it renders when viewed through IE or Firefox. They also had a small tutorial on how to take a regular Windows forms application and quickly convert it to a full blown ASP.Net web application. This would have been awesome, except we don’t use Windows Forms controls for anything, not even our forms. Everything is from Dev Express, so it doesn’t convert so hotly. I did some more research and you can get those 3rd party controls to work, but it’s not the greatest or easiest to work with. Their quick solution would eventually turn into a code nightmare. So much for that.

Looks like it’s time to dig out the new routing engine in ASP.Net and start wiring up some of my own code. I really wanted to use MVC, but if the UI is going to suck, our users will absolutely hate us.