Business Systems Analyst - Clearing - SQL Server - ASP - VB (IL) Next Step Systems US-IL-Chicago Post A Job | Post A Resume

In Part 1 we looked at the fundamental differences between a classic ASP page and an ASP.NET page. In this part we'll examine what, exactly, we need to change in our ASP pages to ease the transition from ASP to ASP.NET.

What we Need to Change
One of the shortcomings with classic ASP is that it encourages developers to write "spaghetti code" script. ASP.NET removes the need for this by providing a seamless object model between page elements (Web controls) and server side code. This integration between Web controls and server-side code allows developers to cleanly structure their page logic in an orderly, non-"spaghetti code," fashion. Therefore, to ease the transition from classic ASP to ASP.NET, it is important that we start creating our ASP pages without using spaghetti code.

While I cannot show you how to directly interract with your HTML elements from your server-side code in the same way that ASP.NET allows, I can show you how to structure your code in such a manner that will make the move to ASP.NET much less painful. Because of the procedural nature of classic ASP, developers are not necessarily encouraged to write modularized code chunks responsible for different units of work (although this can be accomplished with using VBScript classes). Quite often tasks such as form validation is grouped in with the rest of the code block and executed in an adhoc manner. Mixing specific units of work in with the main block of code makes it harder to write re-useable chunks of code and also makes it much more difficult to trap errors where they occur and provide helpful error handling.

This shortcoming has been corrected by Microsoft when they were creating ASP.NET, and as such they have provided special Web controls for a plethora of common tasks, such as: form validation, uploading files from the client to the Web server, etc.

ASP.NET makes up for these shortcomings inherent in classic ASP by providing a Web page life-cycle with certain events and properties that can be programmed against. (Technically speaking, each ASP.NET page is, essentially, an instance of the Page class, one of the many classes found in the .NET Framework SDK. This class abstractly represents a Web page: its events represent the events that occur during the life-cycle of a Web page; the properties represent the various states and parameters that describe a Web page. Each ASP.NET page has a sequence of events that occurs during it's life-cycle; additional events can also occur when as a Web visitor interacts with a Web page's Web controls (such as after the user clicks on a submit button). Let's look at the sequence of events for the Page object:

The ASP.NET Page Object Event Cycle
Event	Occurs When?
The Page object and its controls are created based on the code in the request .aspx file	Initial load & Postback
The Page object and control properties are recovered from a hidden field	Postback only
The Page object controls are updated based on the user's input	Postback
The Page_Load event fires	Initial load & Postback
Change notification events fire	Postback
The Page object and control properties are saved to a hidden field	Initial load & Postback
The Page object and controls are rendered into w3c-compliant HTML	Initial load & Postback
All created objects and memory usage is cleaned up	Initial load & Postback

Creating a Template for Classic ASP to Ease Migration to ASP.NET
Since we've identified the fundamental differences in ASP and ASP.NET, we should now turn our attention as to how we can create our ASP pages today to ease the migration to ASP.NET in the future. For this article we will create a basic ASP "code template" that, when used, will mimic the events that occur during the life-cycle of an ASP.NET Web page.

The first function in our code template will be a function whose purpose is to mimic ASP.NET's Page_Load event handler. Of course, with ASP, this won't fire automatically when the page is requested from a Web visitor. Intead, this Page_Load function will have to be called explicitly by the developer to start the event life-cycle for our code template (we'll examine this in more detail later on in this article).

In ASP.NET the Page_Load event handler typically checks the values of two Page object properties: Page.IsValid and Page.IsPostBack. The Boolean IsValid property is useful when ASP.NET's form validation Web controls are used. (To learn more about form validatoin with ASP.NET be sure to read: Form Validation with ASP.NET: It Doesn't Get Any Easier!) The IsPostBack is a Boolean property revealing if the page has been posted back.

The Page_Load function for our classic ASP code template can be seen below. Note that the example below does not check to see if the page is valid or if it is a postback... we'll look at how to do that later. The example below simply shows an empty Page_Load function:

<% Sub Page_Load () 'Execute code that should run when the page first 'loads here. Also a great place to check the 'IsValid/IsPostBack properties we'll be examining shortly End Sub 'Create the psuedo event. call Page_Load () %>

The beauty of modularizing your code in this manner is that each specific unit of operation has it's own handler and it's own error handling, so that you control the flow at each point of the operation and you are able to trap errors when and where they occur, rather that just randomly sprinkling calls to a generic error handler throughout your code. Knowing the exact nature and location of errors is most of the battle in providing an intuitive error handling mechanism for your end users.

Now that we have our Page_Load function for our template, we need to examine how we will obtain and populate the IsValid and IsPostBack properties in our code template, which we'll do in Part 3.