WLQuickApps.SocialNetwork Themeability

  • We use ASP.NET themes for the design, so the process for changing that is the same as you would use for any other ASP.NET site. Someone would need to get familiar with the skin and CSS files, but then they could do just about anything. 99% of the differences between all the demo sites we've built were done by changing the theme files. If someone is completely happy with the way the site works, but wants to completely change the design, this is pretty much all they need to do (and update Web.config appropriately).
  • If someone wants to customize the site at a deeper level, such as by rearranging the pages, adding new pages, etc, they can hack it however they want. However, if they want to maintain multiple versions of the site within the same source tree (or just don’t want to change the default version of the site), we added a theme override module to make this very easy. For example, we use different Default.aspx pages for each demo site but didn’t want to branch the site for each, or deal with crazy maintenance by hacking a special naming convention for the files (we originally did this and had files like AWRDefault.aspx, ABCDefault.aspx, etc, and it was unmaintainable).
  • The theme override module looks at every request as it comes in and checks to see if there is an overridden version of the file in a root folder with the name of the theme. For example, if you have configured the site to use the “AWR” theme in Web.config, each request is checked against the “AWR” folder to see if the file was overridden. As a result, when a request comes in for “~/Default.aspx”, we check to see if there is a file at “~/AWR/Default.aspx”. If so, we redirect the browser to it. If not, we serve the original. The nice thing about this is that you can be very selective as to which pages you override. You can also do anything you want in the theme subfolder, such as adding custom controls and code, etc, which makes it easier to maintain since it’s separate from the rest of the project.
  • There are a few things people will need to watch out for:
    • The theme overriding uses a Response.Redirect and not a Server.Transfer. As a result, the overridden pages should be designed based on their actual location within the site (and not the location of the page they’re overriding). For example, if you have ~/AWR/Default.aspx, it should not assume that there is a relative Landing.aspx page, but should use /Landing.aspx, or better yet ~/Landing.aspx to let ASP.NET figure out where that page actually lives.
    • The theme overriding could be slightly more optimized. For example, it could check to see if the current request begins with the theme folder, and then not bother to check if there’s yet another nested version of the file within that folder. The performance difference is negligible, so we left it simpler.
    • If you autoredirect a page, you need to be careful about loops. For example, if you have ~/AWR/Default.aspx redirect to ~/Default.aspx, be aware that this will loop infinitely if the theme is AWR since the module will keep pushing the browser back to the overridden version.
    • Theme overridden pages should point links to the default version of a page whenever it exists. For example, if you override with ~/AWR/Default.aspx and ~/AWR/Landing.aspx, any links from ~/AWR/Default.aspx to the landing page should go to ~/Landing.aspx in case someone decides to remove the override at some point. If the page is overridden it’ll automatically get forwarded there anyway, so it isn’t a problem to be safe.
    • Site themes should not use the names of folders in the root, such as App_Code, bin, Friend, etc. This probably isn’t likely to happen, but could result in unexpected behavior due to the theme overriding mechanism.
  • We also use ASP.NET master page and sitemaps, which we tend to keep in the theme override folder, although they could actually go anywhere. It’s likely that people would want to add their own versions of these when building a new design.

Last edited Jan 22, 2008 at 4:37 AM by alogan, version 1

Comments

No comments yet.