BooProd.Core - Context sensitive URL

• Download source files - 34.2 Kb

Introduction

The purpose of this article is to assist .NET developers to build dynamic web sites and especially construct URLs easily. You can find here an easy XML configuration file for defining your own Web Site definitions, and also easy tips for generate context sentive URL on the fly. This package can save you a huge amount of time for building and testing your web sites.

What is a context sensitive URL ?

When you create a web site on your local machine and don't want to use relative URLs, then all URLs in your HTML code seems like "http://locahost/MyApplication/Page.html". When you try to put your web page on the Internet, there's a big problem. All the URLs are pointing to your local web site and not on your production web site like "http://www.MyDomain.com/Page.html". Obviously, you can use relative URLs but in some cases, it is not possible. The solution is to rename all the URLs in your page. I joke, this is not very smart! In fact, you need this URLs to be computed dynamically, depending on which server the page is generated. This is what I call a context sensitive URL generation.

Background

There's no background needed for using this package.

Installation

Download the ZIP file and extract it on your 'c:\temp' folder. You must have this two folders created :

• BooProd.Core.TestDynURL
• Inetpub

First, copy the 'BooProd.Core.TestDynURL' folder (inside 'c:\temp\Inetpub\wwwroot') in YOUR 'c:\InetPub\wwwroot' folder. Then in IIS, create a new Web application giving the name 'BooProd.Core.TestDynURL', pointing to 'c:\InetPub\wwwroot\BooProd.Core.TestDynURL'. Then, double-click on the ''c:\temp\BooProd.Core.TestDynURL\BooProd.Core.TestDynURL.sln' file.

The solution has been made with VS.NET 2003 v7.1.3088, with .NET Framework v1.1.4322 SP1.

See also

You can refer to my article "BooProd.Core DBAccess" treating the context sensitive database access.

Using the code

The purpose of this article is to help you create context sensitive dynamic URLs. First, you need to configure your web sites definitions and initialize the package in order to use it. Then, we shall see some explicit use for creating full context sensitive dynamic URLs for images, forms and redirections.

Local vs Production

One of the main functionality this package is based on, is the detection of the execution context. I consider that, in the life cycle of a project there are two main stages. The first stage is the creation of the project on your local computer. The second stage is to deploy this project from your local computer to your production server. Sometimes, there's a pre-production server, but we'll consider it as a production server. Between the local and the production version of your files, the less modifications you do, the better it is. The purpose of this package is to have zero modification between local and production version.

In order to use context sensitive information, we need to know at execution time, if we're on a local execution context, or on a production execution context. I've grounded the context detection on the host IP address executing the application. When you work on your local machine, you're generally on a private network and your computer has for example IP address 10.1.1.5. Suppose you work is with another colleague of your team, with host IP address configured as 10.1.1.10. You need to be considered both as executing the project in a local context. So, I'll define that the common IP prefix between you and him will be "10.1.1.". All the hosts IP addresses starting with "10.1.1." will be considered as executing in a local context, and all the others as executing in a production context. For example, a host with private IP address "10.2.2.1" or public IP address "209.171.52.99" will be considered as a executing in a production context.

Configuration using an XML file

The first thing to do is to fill the XML config file with your own web sites parameters. A template of this file is in the BooProd.Core project, with name ExeContextTemplate.xml. ExeContext stands for execution context.

The first XML node is ExeConfig. The version attribute is for versioning the XML file for future use and for checking compatibility. The local_ip attribute allows to determine the prefix of all IP addresses considered as local.

The next XML node is ExeDBList, describing the context sensitive connections to your databases. You can refer to my article "BooProd.Core DBAccess" treating context sensitive database access.

The next XML node is ExeWebSiteList, describing all your web sites URLs. Each web site is detailed by an ExeWebSite node. The alias attribute is a keyword (an alias) that will be used in your HTML or C# code each time you'll need get the context sensitive URL of this site. The url attribute is the URL used for accessing your site, depending of a local or production execution context. You can put as much ExeWebSite nodes as needed.

...
<ExeConfig>
 <version>1.2</version>
 <local_ip>10.1.</local_ip>
</ExeConfig>
...
<ExeWebSite>
 <alias>CODEPROJECT</alias>
 <local><url>http://localhost/BooProd.Core.TestDynURL</url></local>
 <prod><url>http://www.code-project.com</url></prod>
</ExeWebSite>
...

Dynamic vs Static Access

Dynamic Access

The first way to access values is to provide the associated alias string defined in the XML config file, like this : ExeContext.WebSite("CODEPROJECT").URL (this will return the web site URL associated with de "CODEPROJECT" alias defined in the XML config file). This works pretty well but you can miswrite the alias, and it could be difficult to debug.

Static Access

The other way is more express and secure. Associated with the ExeContextTemplate.xml is provided an ExecTemplate.cs class. This class acts as a direct shortcut to values defined in the XML config file. This is more secure because you can check at compilation time that all your aliases are valid, and therefore the associated information. The drawback of this method is that you must write a small class and all aliases must map the XML config file. But, access to the information will be the quickest : ExecTemplate.WS_CODEPROJECT.URL (this will return the web site URL associated with de "CODEPROJECT" alias defined in the XML config file, using the XS_CODPROJECT property of the ExecTemplate class).

Initialization

Once the configuration file has been made, you have to initialize the package before using it. The best way to do this is on the Global.asax. This allows you to configure the execution context only one time, for each new Session.

...
protected void Session_Start(Object sender, EventArgs e)
{
  ExecTemplate.autoInit(Session);
}
...

Then, on each .aspx page you need to initialize the execution context. It's not an initialization from scratch, we use in fact the reference, created on the Global.asax, and stored in a Session variable.

...
private void Page_Load(object sender, System.EventArgs e)
{
    // Placer ici le code utilisateur pour initialiser la page
    ExecTemplate.refresh(Session);
}
...

Now, you're ready for generate URLs dynamically, depending on the execution context, but in a totally transparent way. The TestDynURL project included in the ZIP file will show you different ways to do it. Unzip it in your InetPub directory. You can then launch the MainForm.aspx file in your favorite browser and see the results.

UML considerations

Don't worry about UML, it's very cool. You don't need to read thoroughly this section, vital stuff being included in the demo project :

Here is the main ExeContext class with the direct access class ExecTemplate.

Points of Interest

1. 1^st of all, may be you don't really understand why you need to treat urls as this ? My feeling is that when you work within a team, everyone has to use the same development rules. So, here is a way to do this.
2. This package will execute itself on a local and a production environment with no modification. This is very cool.
3. This package is extensible as I only implement one useful feature. Feel free to add your own context sensitive tools.

History

This is my second article, but in my next ones (coming soon I hope), you will find some amazing application of this features, very useful in life cycle development ...

• v1.1 - 2004/12/22

Installation explained.

• v1.0 - 2004/12/07

First version.