A quick overview of building WebSites before ASP.NET

To get up and going, producing production-ready websites, quickly with ASP.NET one needs to know what it is, and how it works.

To understand what ASP.NET is, what's so special about it, and why its productive to use it, one really needs to take a little time to understand how websites were created before ASP.NET was made available, what their problems were, and how ASP.NET solved it.

In PHP, ASP, and all other webscripting structures prior to ASP.NET, the webdesigner created webpages by assembling page fragments with includeand echostatements.

A simple structure would be something like page.asp that included header.inc, body.inc, footer.inc.

In the case of PHP, this would have looked somewhat like the following:

Starting with the entry page.php:

<? include "variables.php"?>
<? include "header.php"?>
<? include "body.php"?>
<? include "footer.php"?>

you can see that it is including other file 'fragments'.

The first  being variables.php where at least one variable is setup for use by the subsequent fragments:

<?$_COMPANY_NAME = "The Firm, Inc.";?>

The next fragment, header.php, can now refer to that variable:

This is the header for <?echo $_COMPANY_NAME?>.

Once the header's out of the way, we can include the core of the page by including body.php:

Hello <?echo ((!is_empty($_SESSION['UserName']))?$_SESSION['UserName']:"Anonymous User";?>

And close up with footer.php:

This is the footer for <?echo $_COMPANY_NAME?>.

This include/echo methodology worked very well: the number of web designers using PHP, and who used to use ASP, attests to this. But it did have at least two basic problem areas, which we will describe below.

Spare Parts Flying in Close Formation

With PHP and ASP, we were creating websites that worked but the whole structure of these bits and pieces held together with include statements was very similar to how I once heard a Vietnam Vet refer to the helicopters they used: "spare parts flying in close formation".

A good PHP, or ASP programmer has no trouble keeping this mess somehow flying: its actually a fun challenge having to remember what piece goes where, in what order they are included, what that const statement refers to, and this ability to remember the whole "castle in the mind", made us think of ourselves as 'webgurus' (more importantly, it made the the people who paid our cheques think of us as webgurus...).

But looking back, I think we were being called webgurus not because what we were creating was really fantastic (although I'm very very proud of some of it) -- but because, in truth, nobody else could figure out how our sites were made.

Things could get so complex, that it appeared that only the original designer could possibly remember what went where, what variables were global, what they were titled, etc. And that really was often for just long enough to do the project. Ask us again 6 months later to urgently add in a new feature, and the whole project was a big blur, that took some lead time to re-analyze the project as a whole to figure out what went where.

To expose just the tip of the iceberg of this problem, look at the above example again: from the point of view of header.phpthere is no indication whatsoever to determine the point at which $_COMPANY_NAMEwas defined. Nor a way to indicate which page included it.  Allow that much 'blindness' in a complex website, and the overview of the whole project becomes ... a nightmare.

Creating the Illusion of State, in a Stateless Environment

The second basic problem with PHP, or ASP, was the fact that an Http server is stateless.

To get around this, and give the illusion of variables that lasted across page requests, we resorted to one of two common script techniques:

1. the Session HashTable,
2. Round tripping of variables on the GET/POST statement.

Using a Sessions HashTable:
Saving variables in the Session HashTable was easy enough:

$_SESSION['MyVar'] = "var to save across all page requests from this user";
$_SESSION['ShoppingCartSum'] = 10000.00; //Well, I can dream, no?

Round Tripping Request variables:

And other than sometimes getting lost in angled brackets, working with Request variables wasn't much harder:

//Pick up the variable from the GET statement:        
$tmp = (!isempty($_REQUEST['MyVar'])?$_REQUEST['MyVar']:0.00;
//Put it into the link going to the next page to round-trip/persist it across pages:
<a href="nextstep.php?MyVar=&lt;?echo $_REQUEST['MyVar']?>>Link to Next Step</a>

Using the Session HashTable methodology makes all pages share the same variables (a bit too sticky in a lot cases).

Using the round-tripping methodology is great for a web designer who isn't planning to integrate with any other person's work -- after a while these URL arguments tend to interfere with each other either by length allowed (total being 1024 for GET), or simply both programmers wanting to use common keys such as 'id'.

The end result is that these 'webgurus' ended up not being able to work together very well, with each web designer having to redesign everything from scratch: the same webmail application, the same contacts application, etc.

ASP.NET offers a way out of these quandaries.