• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 354
  • Last Modified:

Using OnAppStart to determine the site's frosting

Nutshell:
How (or if) to use the Global.asa as a way to clone a series of sites with a common code base but varying front-end elements.

Bigger Picture:
I have a donut shop and have found that if I deploy a series of websites - one for each of the donut types I manufacture (myGlazedDonut.com; mySprinkledDonut.com; myPlainDonut.com, and so on) - I'm better able to serve the interests of my customers than if I host one central 'DonutsRUs.com' domain. (taken, darnit).

I'm thinking the best code reuse will be one backend tier that drives multiple websites, one per frosting option. So I'd like to code a webapp that understands which frosting facade to present based on which domain it's running within.

So if the app wakes up to find it's running in the 'myFrostedDonut.com' domain it knows to display 'sales@myFrostedDonut.com' for the email address, it knows which .jpgs to use for Banners and Footers, it knows which google-analytics code to use. It even knows that on the 'Contact Us' the reader will see: Hi, from your loyal friends at Plain Donuts. Did you know that plain donuts are much better for you than those fattening things found at places like myFrostedDonuts.com.

Point is there are a lot of different 'search/replace' types of operations taking place in code. Usually I've used the web.config to store global variables but the above scenario is more complex than just a database connection string - there are a lot of exception conditions to account for, not every property has a one-to-one relation to each other domain.

I'm thinking I want to add logic at the Global.asa but need to see some examples of how others have approached similar problems.

thx
0
juststeve
Asked:
juststeve
  • 2
1 Solution
 
ivan_vaguninCommented:
Hi! There are many ways to accomplish what you want, first I would advise to keep reusable in a separate library.
Then, you can make different site look using different master pages or css classes while using the same code, the other option is to use variation controls (controls, that renders different content based on some condition).
If you prefer variation controls, then you can place mode param in web.config or Appliction param collection - these are most suitable places because they are available across all application. If you prefer not to use web.config, then you can init Application param in global.asax, based on current url, like this:

protected void Application_Start(object sender, EventArgs e)
{
    if(string.Compare(HttpContext.Current.Request.Url.Host, "myFrostedDonut.com", true) == 0)
   {
       HttpContext.Current.Application["SiteMode"]  = "Frosted";
   }
}

Then in your code you can read it like:
string mode = Application["SiteMode"] as string;
0
 
juststeveAuthor Commented:
I'm not clear on the difference between web.config-based vs your reference to variation controls. How is something created in global.asax less available than web.config?

thx
0
 
ivan_vaguninCommented:
The web.config-based solution is not vs. variation controls. Instead, the variations can be implemented using web.config based parameters. Parameters declared in web.config and parameters in HttpContext.Application collection have the same scope - they are available at application scope. The difference is in the way you can read and modify the parameters. If you use HttpContext.Application you can set parameters programmatically only, if you use web.config then you can set parameters by editing web.config.
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now