How to detect page type in masterpage code behind

Topics: Themes
Aug 27, 2010 at 2:48 PM

Hi,

I have dug through the code base, searched Google, this site & StackOverflow, and even downloaded a bunch of themes in case I stumbled over the solution.

In this section of the site:

http://blogengine.codeplex.com/wikipage?title=ThemeCreation&referringTitle=Documentation#MasterPage

it states:

3.4 - Code behind Considerations

While the standard BlogEngine.NET themes currently don't use the code behind, it doesn't mean it can't be used.

This is a great place to check what page (or type of page) is being displayed and turn on/off sections of the master page among other things.

 

Can anybody please enlighten me as to how I can detect what kind of a page is being displayed? IE is this a category view, or a post view etc?

 

The scenario I am trying to develop is to insert a custom css reference that will modify the header graphic under certain categories. I will also need to customise the individual post view page if it has this category in it.

 

 

I have tried to tackle this at the masterpage level but im stuck as i dont know how to detect the post type, category, etc.

I have started to tackle this at the post.aspx / default.aspx but i am reluctant as it would mean hardcoding references to themes in the outer pages. I'm not looking for the ultimate generic solution but this feels a little bit too messy for my liking...

 

Thanks for any advice!

Aug 30, 2010 at 6:40 PM
Edited Aug 31, 2010 at 3:14 AM

Check out the Request.RawUrl property - you may be able to set up an if block in that to do what you're wanting to do.  That's the technique I'm using to hide things in the site.master file when the user is not viewing the "home" page for the site.  You might end up with "/category/?id=[guid]" - while the string is long, the GUID will not change, so you could use that in the theme.  You can also take the GUID and look up the nice name of the category in Category.Categories collection, if you'd rather use the nice name.  I'd probably go with the GUID myself, simply because there's not a way to change it through the UI, whereas you could change the category name.  If I had to check it more than once, though, I'd probably make a static string to use.

Some pseudo-code follows - it hasn't been tested, and I'm not 100% that this is the format of the URL, but the idea is the same...

 

 
public partial class site : System.Web.UI.MasterPage
{
    private static string FOOBAR_CATEGORY = "[guid_characters]";

    protected void Page_Load(object sender, EventArgs e)
    {
        if (Request.RawUrl.EndsWith("/category/?id=" + FOOBAR_CATEGORY))
        {
            // Profit!
        }
    }
}

 

Sep 9, 2010 at 1:22 PM

Hey,

Thanks a lot for your advice. It clarified the path I went with. In the end I ended up with some more robust code which looks like this:

  private bool IsCategoryDisplayRequest()
  {
      string PageRequestUrl = BuildPageRequestUrl("default.aspx");

      return (Request.Url.PathAndQuery.ToLower().StartsWith(PageRequestUrl, StringComparison.InvariantCultureIgnoreCase)
          && !string.IsNullOrEmpty(Request.QueryString["id"]));
  }

  private string BuildPageRequestUrl(string requestPage)
  {
      string formatString = string.Empty;

      if (Request.ApplicationPath.EndsWith("/"))
      {
          formatString = "{0}{1}";
      }
      else
      {
          formatString = "{0}/{1}";
      }

      return string.Format(formatString, Request.ApplicationPath, requestPage);
  }

 

I used this to detect if I was currently processing a category request and then I extracted the id from the Request.Querystring["id"] rather than examinig the RawURL property. I figured it was too brittle to check the string directly as simple changes could break it (such as analytics tracking ids).

 

The BuildPageRequestUrl() builds the url without having to hard code anything and gets around the concatenation issues between a root application (ApplicationPath = "/") and a sub application (ApplicationPath = "/SubApplication").