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)
{
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
- 1st 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.
- This package will execute itself on a local and a production environment with no modification. This is very cool.
- 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.
