Blog Host: Andrew Young - Senior Application Developer, Wheelock, Inc. READ ENTIRE BIO

In summation, I would add what is already apparent: The .NET framework is an example of a truly object-oriented infrastructure. Each Web form that you add to your project is linked to an automatically generated code-behind page. The code-behind page contains a namespace reference to your project and defines the class that is your Web form. This class can extend any class or classes within the .NET framework, provided that you add a reference to the DLL file that contains the components that you are extending. For anyone with a CS background, this is nothing new…it is, literally, an example of all of those concepts we learned in our CS college classes way back when, only now they are being applied in a working GUI IDE that produces much more extensive and eye-pleasing results. I remember thinking about how all those classes were being wasted on linked lists and seemingly useless dissertations on binary tree recursion. But the familiarity I innately experience when looking at the design of this IDE makes me realize that the whole time a discipline in a line of thought was being established. Although many of the classes in the .NET framework are unfamiliar (there are so many, it would take years to know them all, if that is really even necessary), it is the concept of the hierarchy and how inheritance works that is the key.

ADO.NET
The improvements to the ADO technology with the introduction of ADO.NET are drastic. This was not an upgrade; actually, it was an overhaul. Yet, with all of the new features and functionality, existing ADO code and objects, like recordsets, will still work. The only thing that I have found not to work, as previously mentioned, is the CDONTS code.

The ADO.NET architecture consists primarily of DataSets, DataReaders, DataAdapters and DataViews. They are presented through the browser via list-bound controls such as data grids, list boxes or drop-down lists. You have many options as to how you build these interfaces when working with Visual Studio.NET.

There are several types of data adapters. Out of the box you have the availability of a SQL data adapter, OLEDb data adapter, ODBC data adapter and an Oracle data adapter. I have not done it, but I don't see any reason why you cannot create your own data adapters as well. Remember, everything in the .NET environment is based upon the namespace that contains the classes or the components of the DLL file that we are referencing. If someone has created a Lotus Notes data adapter, for example, simply copy that DLL file locally and add it as a reference to your project to gain access to its classes.

The names of the data adapters are self-explanatory. You can use the OLE or the ODBC data adapters to connect to miscellaneous data sources such as dBase, Access, FoxPro, etc. Let's continue in this example by revisiting our CD project from the ADO discussion.

To use a data adapter, you must supply it with an accompanying data connection and generate a data set. You will then fill the data adapter with data from the data set and bind it to a list-bound or Web-bound control. It is very easy to do this by dragging and dropping the objects onto your Web form. This will invoke wizards that will guide you through the configuration process and automatically create all of your code within the code-behind. Let's look at two examples -- one is an ODBC application done in VB, the other an OLE application done in C#:

First, let's look at the ODBC approach. Begin by creating a data connection. You can either code it manually, create if from the server explorer or drag and drop an ODBCConnection object onto the Web form. I have found the easiest way to create the connection in the server explorer, which will make it an available source when configuring your data adapter. To do this, open the server explorer and right click on data connections, then select "Add Connection." Choose "Microsoft OLE DB Provider for ODBC Drivers" as the provider, then choose to build your connection string via the button in the connection area. This will invoke a wizard that creates a DSN entry within your application. This will look very familiar to anyone who worked with early versions of ASP for Access connectivity. Upon completion, you will return to the Web form, and the connection will be visible as a data connection in your server explorer. Drag and drop the ODBC adapter object onto the Web form and complete the wizard, pointing it at this connection. The wizard will even allow you to create queries and insertion and deletion statements into your adapted object. When finished, right click the adapter and select "Generate Dataset." You should be able to accept the defaults and click OK. Next, drag a data grid onto the Web form. Right click the object and select "Property Builder." This will generate a full configuration panel for your grid. Point the data source to the data set you just created, and point the data member to the table in that data set. The remaining tabs of the property builder will allow you to easily configure the desired look and feel of the object. You can even set the paging size of the grid, which will allow page scrolling of the data contents.

Upon completion of these steps, it's time to add the three lines of code to make the application work. It would appear that it would work as is. At this point, you will see that your data grid column headers have taken on the names of your fields from the Access database. But we have not yet actually bound the data to the data grid server control. In the code-behind page, you will notice that lots of things have been added. In your page load event, add something like this (depending on the names of your objects, you might need slight adjustments):

OdbcDataAdapter1.Fill(Me.DataSet11)
DataGrid1.DataBind()
DataGrid1.Visible = True

The OLE approach is almost exactly the same. However, when you create your connection, use "Microsoft.Jet.OLEDB.4.0" as your provider. Configure the adapter, generate a dataset, then add the same code, replacing it with the OLE objects, to bind the data to the Web control:

oleDbDataAdapter1.Fill(this.dataSet11);
DataGrid1.DataBind(); 

Converting existing HTML pages to Web forms
A very quick and painless way to create some ASP.NET pages is to work with some of your existing HTML pages. It is a simple, built-in process that will help get you started. To do this, follow these steps:

• Create a new ASP.NET Web application in whatever language you prefer. Name it accordingly.

• From the Project menu, select "Add Existing Item." Change the "files of type" selection to "All Files(*.*)." Browse to the HTML file you want to convert, and select it.

• You will see the file that you selected located now within your solution explorer. Right click on it and select "Rename." You will be prompted to create a class for the new page. Select "Yes."

• Double click on the page in design view. This will open the new code-behind page that contains the class that you just created. Switch back to the UI page, and toggle to the HTML view. You will notice that a new @Page directive has been added to the top of the file. Your conversion is a success.

Thanks to all of you who submitted questions and read this blog…for those of you who have submitted questions that I have yet to answer, keep checking back, because I will. Good luck to everyone in his or her development hopes and aspirations.
Posted by Andrew Young Key points of ASP.NET, part 2
22 SEP 2005 23:19 EDT (03:19, GMT)
There is so much more to cover in so little time. So let's get into it. Let's continue by looking at the postback functionality. Postback refers to an inherent ASP.NET form design. Forms post information back to the ASP.NET page for processing, at the server. Without modification, only the click event of a button control will invoke a form to be posted back to the server. All controls, however, have a built-in property that will force a postback; it is called the "AutoPostBack" property. Adding AutoPostBack="True" to any control will force it to postback to the server immediately as events for that control occur.

You can also manipulate postback processing using the Page.IsPostBack property within a conditional statement. Let's look at a simple example. I rewrote yesterday's project using C# to keep the discussion well-rounded:

private void Page_Load(object sender, System.EventArgs e)
  {
   if (!IsPostBack)
   {
   //this code only executes on initial page load
    sPage = (WebForm1) Context.Handler;
    if (sPage.Property1 == "test")
    {
     TextBox1.Text = "You are testing"; 
} 
    Else
{
     TextBox2.Text = "You are not testing";
    }
    
   }
   //all code here will execute upon each request
  }

Postback improves performance in that it enables us to eliminate redundant interactions between the client and the server. Ignoring that aspect of your project will predict its overall performance efficiency.

Demystifying the namespace
Namespaces logically group the classes that comprise the .NET framework. They can be used by any .NET-based language and are usable in your application by types; that is, each namespace contains types that you can use. To use the classes in a namespace, you can either type each full namespace hierarchy or declare it with a statement at the beginning of your application. A new C# ASP.NET Web form provides several examples of the declarative statement for a namespace:

using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Web.UI.WebControls; etc…

TextBox1 = new TextBox();
TextBox1.Text = "You are testing";

System.Web.UI.WebControls.TextBox = new System.Web.UI.WebControls.TextBox();
TextBox1.Text = "You are testing";

The object class of the System namespace is the base class of all classes, the root of the .NET Framework type hierarchy. It exists as a component within the mscorlib.dll file.

It is critical when developing in the .NET environment to understand how the classes are deployed. The polymorphism of the components is the best way to break the ice. From this study you can branch out into the concepts of overriding and overloading members of base classes and become acquainted with derived classes. Mastering these concepts in my opinion will come from practice with interfaces, inheritance and abstraction. From what I have seen, the whole class concept and class initialization is analogous to C++. It is, however, much more advanced than the C++ I was working with on a DEC Alpha Unix box in college. But the concepts haven't changed.

Again I refer to the .NET Framework users guide. I cannot go beyond the scope of the application we are already playing with to exemplify the concepts of the classes…understanding the things I mention above requires study and practice. Lookup "Polymorphism in components," and take it from there.

However, we can see some instances of inheritance implementation at work in our existing project. For example, this line of code:

public class WebForm2 : System.Web.UI.Page

public class WebForm2 : Page

override protected void OnInit(EventArgs e)
  { …

 protected virtual void OnInit(EventArgs e);

An understanding of the page event life cycle is entirely relevant and worthy of some discussion. ASP.NET forms are, by design, adhering to a built-in cycle of events that always occur in the same order. This affects, or can influence, both the performance and functionality of the application. Whenever I see a built-in processing sequence, I know that it is there for good reason and can potentially become a powerful tool in my application. These events occur in the following order: Page_Init, Page_Load, Control events and Page_Unload. The Page_Init event initializes Web server controls on the page. Page_Load runs every time the page is requested. Control events run all change events, such as textbox or datagrid changes, and action events such as button clicks. Page_Unload runs when control is passed to another page or when the page is simply closed. These events can be creatively manipulated in such a way that they "jump through hoops" for you.

As an example, let's work with the code generated in a new ASP.NET VB Web project. This code is located in the code-behind page of your new project. Expand the area labeled "Web Form Designer Generated Code" to access the Page_Init subroutine…the Page_Load event is already visible by default.

We have an ASP.NET Web project, which is designed for inherently dynamic applications by nature. Consider for this example that we have two pages in our application, WebForm1 and WebForm2. We will arrive at WebForm2 being supplied with preliminary information from WebForm1. Based upon the information from WebForm1, we are going to create distinct sets of text boxes in WebForm2 and populate them with data. Let's create a text box and a button on WebForm1. We will pass the value of this text box to WebForm2. We are not passing values between pages via a call to the Request object any longer. Web forms are in reality a class. Things are now completely encapsulated. In the code-behind page of WebForm1, we create a public access property within the class that returns a string:

Public ReadOnly Property Property1() As String
        Get
            Return TextBox1.Text
        End Get
End Property

Server.Transfer("WebForm2.aspx")

Public sPage As WebForm1 = CType(Context.Handler, WebForm1)

<% @ Reference Page="WebForm1.aspx" %>

Protected Form1 As System.Web.UI.HtmlControls.HtmlForm
Protected WithEvents TextBox1 As System.Web.UI.WebControls.TextBox
Protected WithEvents TextBox2 As System.Web.UI.WebControls.TextBox 

Private Sub Page_Init(ByVal sender As System.Object,
 ByVal e As System.EventArgs) Handles MyBase.Init
        If sPage.Property1 = "test" Then
            'display in upper left
            TextBox1 = New TextBox
            TextBox1.ID = "TextBox1"
            TextBox1.Style("Position") = "Absolute"
            TextBox1.Style("Top") = "25px"
            TextBox1.Style("Left") = "100px"
            Form1.Controls.Add(TextBox1)
        Else
            'display in upper right
            TextBox2 = New TextBox 
            TextBox2.ID = "TextBox2"
            TextBox2.Style("Position") = "Absolute"
            TextBox2.Style("Top") = "25px"
            TextBox2.Style("Left") = "550px"
            Form1.Controls.Add(TextBox2)
        End If
        'CODEGEN: This method call is required by the Web Form Designer
        'Do not modify it using the code editor. 
        InitializeComponent()
    End Sub
Private Sub Page_Load(ByVal sender As System.Object,
 ByVal e As System.EventArgs) Handles MyBase.Load
        If Not Page.IsPostBack Then
            If sPage.Property1 = "test" Then
                TextBox1.Text = "You are testing"
            Else
                TextBox2.Text = "You are not testing"
            End If
        End If
    End Sub

This is a very simple example that can be expanded to perform many more advanced processes. Logging into an application, for example, with ADO.NET integration, or reading usernames and passwords from an external data source. I based a recent project for an online auto warranty company on this functionality. The make and model of the auto selected in WebForm1 acted to determine which dataset to fill and bind to several listboxes in WebForm2, such as potential prices and available coverages for that vehicle, pulling the information from a SQL box. I should go into the significance of the postback operation, but I am too tired...tomorrow. Good night.
Posted by Andrew Young ASP.NET
20 SEP 2005 00:00 EDT (04:00, GMT)
Windows application development was previously an area restricted to C and/or C++ developers. The .NET framework allows developers to leverage their existing skills to develop pretty much any type of application. Even Java developers will see familiar code when they create C# ASP.NET Web applications. For our ASP.NET topic, the two languages we will use are VB and C#. All languages support by the .NET framework offer the same performance, essentially. It is a matter of preference which language you choose to use. When compiled, the .NET-based language will be converted to Microsoft Intermediate Language (MSIL). MSIL is then compiled to native code by the same compiler at runtime. In other words, the MSIL is handled by the runtime. The common language runtime is language and platform-independent. The runtime uses a JIT compiler to process the MSIL-generated code into native code (another Java-induced concept). At this point, the compiled code is cached so it does not need to be recompiled for each request. The runtime is a managed environment…garbage collection and security is automatically provided. You do not need to create destructors within your classes. With this approach and the use of the now industry-standard XML, we as developers can spend a lot less time considering compatibility issues and more time on the logic of our applications.

For what I have used it for thus far, I love working with Visual Studio.NET. It is a rich, streamlined IDE that allows excellent drag and drop functionality of any object you can imagine. I have only loved one other IDE in my life, that being the Lotus Domino Designer…and I cannot really compare the two. I will say, though, that I favor the Microsoft approach in terms of the way that they have maintained and extended VB for Web development. IBM should be doing the same for their LotusScript developers, the core of that development community. Perhaps they have with Domino 7, I haven't had a chance to really look at it as of yet. I do know that they have created an integral component for XML-based Web services, though. Anyway, that is an entirely separate discussion so let me stop rambling.

The .NET framework, simply stated, consists of namespaces (DLLs) or class libraries. This is an extensive collection of reusable data types. It is worth noting that namespaces are arranged hierarchically for ease of reference. You can add to this library, which essentially creates for us, as developers, exposure to the design of our own .NET framework. Creating a class library creates an actual DLL file. All you need to do to access this component from other programs is add a reference to that DLL, then instantiate the reference via its namespace and class name. We will go into some examples of this tomorrow.

Posted by Andrew Young Summation and a troubleshooting tip
19 SEP 2005 22:38 EDT (02:38, GMT)
I have found that most errors are related to connection objects and incorrect paths or permissions. Remember that your server MUST have access to your database in order to perform actions on it. This access is granted via the IUSR_<IIS servername> username. If you are using a different backend data source, such as SQL, you must pass a valid username and password to the SQL database if it is password protected.

There are built-in server variables available that will assist in you in troubleshooting connection issues. One specific server variable is the "PATH_INFO" variable. As an example, the code below represents a page that will help to resolve the path to your database. Place this page in the same directory as your database, and view it in your browser. It will display the relative and absolute paths. From there, you can copy the absolute path displayed to your connection string. Remember to remove the name of the ASP page from the string (as it will be displaying whatever you name the page below) and replace it with the name of your database.

<html><head><title>Path Information</title></head><body>
<% Dim pathinfo, physicalpath
pathinfo = Request.ServerVariables("PATH_INFO")
physicalpath = Server.MapPath(pathinfo) %>
<b>The relative path to the file is:<br><% = pathinfo %><br>
<br>The physical path to the file is:<br><% = physicalpath %><br><br>
</b></body></html>

<% Dim objMailUser ,bodyStringUser
Set objMailUser = CreateObject("CDONTS.NewMail")
'(build the body of the email …)
bodyStringUser = "This email is a confirmation for your recent CD-ROM request." &
 Chr(10)& Chr(10) 
bodyStringUser = bodyStringUser & "Your Order ID is: " & Session.SessionID &
 Chr(10) & Chr(10)
objMailUser.MailFormat = 1
objMailUser.From = "webmaster@mycompany.com"
objMailUser.To = Session.Contents("email") 
objMailUser.Subject = "Receipt for your CD-Request"
objMailUser.Body = bodyStringUser 
objMailUser.Send 
Set objMailUser = Nothing 
Session.abandon  %>

'new code added on 6/23/2005
'IIS 6.0 does not support CDONTS, CDOSYS is the successor
'this code is a migration to CDOSYS - A. Young
Dim iMsgUser
Set iMsgUser = CreateObject("CDO.Message")
Dim iConf
Set iConf = CreateObject("CDO.Configuration")

Dim Flds
Set Flds = iConf.Fields
Flds("http://schemas.microsoft.com/cdo/configuration/sendusing") = 1
Flds( _
 "http://schemas.microsoft.com/cdo/configuration/smtpserverpickupdirectory") _
  = "c:inetpubmailrootpickup"
Flds.Update

Set iMsgUser.Configuration = iConf
iMsgUser.To = Session.Contents("email")
iMsgUser.From = "webmaster@mycompany.com"
iMsgUSer.Subject = "New CD-Request"
iMsgUser.TextBody = bodyStringUser
iMsgUser.Send          

Preferably a need will arise and your development will not be just for practice. Taking it in small doses and testing each function as you go, will allow you to be successful and not get discouraged. As it is with ASP.NET, there is minimal to no learning curve when it comes to LotusScript or VB developers. It's just a matter of getting to know the objects and how they are applied. On that note and in conclusion of the ASP discussion, the ASP Object Model:

Posted by Andrew Young Script integration -- server-side, client-side and ADO, part 4
16 SEP 2005 21:28 EDT (01:28, GMT)
Continued from yesterday's entry…

From this point, it is simple. The code of the cdadminupdate.asp page will use a duplicate approach. Now that we have stored all of our data in precisely named application variables, we have a copy of each selected record in memory. When the update button of this page is clicked, we initiate the next page. Again, we look at our "isValidated" Session variable (here it prevents someone from attempting to access the page directly without logging into the application). Next we ensure that at least one record has been selected. If not, we do not need a refreshed page, so we use the back method of the history object to return to the previous page. (Again, I like the appearance of the Msgbox, and, at this point, it maintains uniformity in code and for the end user.) We use the variable where we stored our total iterations ("totalRecords"):

  Response.Buffer = "true"
  Dim checkBox, name, email, fullAddress, address, sessID, signup, checkString
  Dim recNumCheck, recInx, actArchive
  if Session.Contents("totalRecords") = 0 then %>
 <script language="vbscript"> 
    Msgbox "There are no records to update." & Chr(10) & "You will now be returned to the
 CD-Orders Page.", 16, "Error"
    document.write(history.back())
    </script> <% end if …

  recNumCheck = Session.Contents("totalRecords")
 'archive selected records
  Do While recInx <= recNumCheck
  recInx = recInx + 1
  checkBox = "checkBox" & Cstr(recInx)
  name = "name" & Cstr(recInx)
  email = "email" & Cstr(recInx)…
   If Request.Form(checkBox)= "Yes" Then
   actArchive = actArchive + 1
   RS1.AddNew %>
         <tr><td width = "20%"><font size="2"><center><% = Application(name)%></center></font></td>
    <% RS1("name") = Application(name)%>
<td width = "20%"><font size="2"><center>…  %></center></font></td>
    <% RS1("sessID") = Application(sessID)%>
<td width = "10%"><font size="2"><center><% = Application(signup)%></center></font></td></tr>
    <% RS1("signup") = Application(signup)
    RS1("datefilled") =  Date()  
    RS1.Update
      RS1.Movenext
   End If   
  Loop
RS1.Close
set RS1 = nothing %>
</table>

Now we must open the active cdorders table and delete the records that we have now archived. Since we are using the same database in the same location, we do not need to recreate our C1 connection object. It is still open and pointed to our database…we just switch back to the active table:

recInx = 0
'now delete these records from the cdorders database
SQL = "SELECT * FROM cdorders"
RS1.Open SQL,CS,adOpenDynamic,adLockkOptimistic,adCmdText
Do While recInx <= recNumCheck
  recInx = recInx + 1
  checkBox = "checkBox" & Cstr(recInx)
  sessID = "sessID" & Cstr(recInx)
If Request.Form(checkBox)= "Yes" Then
If RS1("sessID") = Application(sessID) Then
RS1.Delete
RS1.Update
…
RS1.movenext
End If
Loop

The current task will involve both adding records to and deleting records from the database tables. We needed to maintain an archive of fulfilled records; therefore, the records that we are "deleting" from the active orders table (cdorders) is first being moved to the archive table (archivecdorders), then deleted from the active table.

I finally concluded that there was no simple way to do this. Perhaps there were UI elements in Front Page or Dreamweaver that might have helped, but I was definitely not ready to accept the overhead that either of those tools would add to the code.

I built the dynamic table mentioned above, along with a checkbox to the left of each record retrieved from the database. You might have noticed one variable that was declared yesterday that was not mentioned…the "recNum" variable, which will be an integer value. In order to know which checkbox was selected, I needed to name them according to the record they represented (a server-side variable recognized by the client as an HTML field). We begin by welcoming the user by login name, with an alert that a timeout will occur after 20 minutes of inactivity. This value is set by the timeout property of the Session object and it is the default. You can alter it with the following syntax:

<Session.Timeout = timeout in minutes>

<% Else %>
  <p align="center"><b>Welcome, <% = Session.Contents("userName")%>. Your login will remain
 valid for all administration pages. 
If you are inactive for a period exceeding 20 minutes, your
 session will timeout and you
will need to login again. If you should close your browser, you will
 also need to login again.</b><br><br>
  <table border=1 cellspacing=0 cellpadding=5 width="100%" align="center"
  bordercolor="#000099"><font size="1">
  <tr><td width = "10%" bgcolor="#CCCCCC"><font
 size="2"><b><center>Filled<center></b></td><td width = "20%"
 bgcolor="#CCCCCC"><font size="2"><b><center>Name</center… 
<% do until RS1.EOF
recNum = recNum + 1
checkBox = "checkBox" & Cstr(recNum) %>

<tr><td width = "10%"><font size="2"><center>Yes<input type="checkbox" value="Yes"
 name=<%Response.write(checkBox)%>></center></font></td>

Still, that only creates a pointer to the checkbox that has been selected. If selected, then checkboxn will equal "Yes." So we have selected checkBox1, for example, that tells us that the first record in the display is now marked for archiving. However, using this field name alone is inherently flawed. Consider if others are concurrently performing actions on the database (e.g., adding or deleting records), the recordset may not be correct (the code will not fail to execute, but our actions may be inaccurate). As mentioned previously, our recordset is dynamic as defined by our cursor type, but our variables and/or field names during processing are not. If someone else is concurrently adding a record, the checkbox integer may now point to a different record than the one we selected in the application. The same thing can happen if someone else is concurrently archiving a record. In order to maintain the integrity of the application, it is imperative to create a mechanism that will repeat the approach of the checkboxes and allow us to match the records up with those values in the page specified in the "action" parameter of the form tag that processes the request. We can do this by using application variables to identify the selected records and store them into memory. Application variables, like session variables, are global in scope to your application:

name = "name" & Cstr(recNum)
email = "email" & Cstr(recNum)
address = "address" & Cstr(recNum)
sessID = "sessID" & Cstr(recNum)
signup = "signup" & Cstr(recNum) 
company = "company" & Cstr(recNum)
fullAddress = RS1("streetAddress") & " " & RS1("city") & " , " & RS1("state") & " " &
 RS1("zipcode") & " - " & RS1("country")

Having established this initial set of local variables to begin the iteration, we can begin using them to create a set of application variables that will store each bit of data for each record as it is displayed. We have an integration of server-side code with HTML. Notice the application variable names -- they are not enclosed in quotes. We are creating each application variable with the name that we created and stored in each string variable. So we have Application("name1"), Application("email1"), Application("address1"), etc. Each iteration will create a set of new variables -- Application("name2"), Application("email2") and so on -- until all data is completely stored within these variables. We are also writing the value of each corresponding field from the backend database to the HTML table as we go. Notice that we create a new session variable, "totalRecords," which stores the integer total representing our number of iterations (records). Essentially what we are doing is using dynamically named application variables in place of HTML field names.

A snippet of this code is below:

<tr><td width = "10%"><font size="2"><center>Yes<input type="checkbox" value="Yes"
 name=<%Response.write(checkBox)%>></center></font></td>
  <td width = "20%"><font size="2"><center><% = RS1("name")
 %></center></font></td>
  <% Application(name) = RS1("name") %>
  <td width = "20%"><font size="2"><center><% = RS1("email") %></center></font></td>
%></center></font></td> <% Application(email) = RS1("email") %>……
  RS1.movenext
  loop
  <close the objects here>….. 
  Session.Contents("totalRecords") = recNum
  %> </table> 

The server-side code below is in blue, and the client-side code is in violet. The explicit option forces variables to be declared and is not required; it simply helps to create clean coding practices. We are using the "Form" collection of the "Request" object, which holds all the form information from the previous page in the application. We are assigning the values that we retrieve to local variables.

Next we must look at the contents of the "adoobjects.inc" file. Here, we are instantiating the ADO objects we will use to read data from an external data source. We can use the "create" method of the "server" object to instantiate all of these object references.

Connection strings and recordsets
Let's examine these statements from the SSI file:

"Dim CS, DRV, DBQ, C1, RS1
DRV = "Driver={Microsoft Access Driver (*.mdb)}; "
DBQ = "DBQ= C:\weborders\admins.mdb;"  "

We are examining the most basic of connection strings -- to an Access database. It consists of three parts.

1. The first part is the variable (DRV), which holds the connection string.
2. The second part is the name of the driver.
3. The third part is the physical location of the Access database.

Next, we can append the location of the database (DBQ) to the name of the driver (DRV), thereby finishing the required parameter for a connection string:

"CS = DRV & DBQ"

"set C1 = server.CreateObject("ADODB.connection")
set RS1 = server.CreateObject("ADODB.recordset")"

Having established our connections in the SSI file, we go back to the ASP file below and perform the following actions.

1. First, we open our connection to the data source, passing our connection string variable (CS) as the parameter.
2. Next, we write a simple SQL command to retrieve all of that data contained within the "cdadmins" table of the database.
3. Finally, we open our recordset. We pass parameters for the simple SQL query and the connection string.

Now we can test whether the request to access this data is valid. We are using the session object to test whether a session variable that we create, "isValidated," is equal to "Yes." Upon successful login, we set this session variable to "Yes," which will be the condition that we are testing to determine whether the result was affirmed. We could have also use the application object in place of the session object in this example. We are using a do loop statement that will navigate until the end of the recordset or until a matching record (consisting of the username and password retrieving from the requesting page) is found. We are preceding the do loop with a test of the "isValidated" session variable, as it would be unnecessary to require a user to log in again if they use hyperlinks on the page to jump to other administrative pages. This condition is applied in this manner to other areas that would require a login as well, so that the administrator will not be continuously prompted to log in to the application.

The conditional statement

"if (RS1("userName") = userName) And (RS1("password") = password) Then"

The next line of code is the final line of inline script that performs the validation:

If Session.Contents("isValidated") <> "Yes" Then %>

Nonetheless, server-side redirection is the better choice whenever possible. Older browsers do not support client-side redirection, which is not much of a consideration these days. However, the ability of the client to disrupt your application is. The client will be able to see changes in the location bar and can potentially stop it. With server-side script, the client cannot stop the redirection.

<!--#include file="adovbs.inc"-->
<!--#include file="adoitems.inc"-->
<% 
option explicit
  Response.Buffer = "true"
  Dim recNum, checkBox, name, email, fullAddress, address, sessID, signup,
 userName, password, SQL

 recNum = 0
 userName = Request.Form("txtUserName")
  password = Request.Form("txtPassword")
  C1.Open CS
  SQL = "SELECT * FROM cdadmins"
  RS1.Open SQL,CS,adOpenDynamic,adLockOptimistic,adCmdText

  If Session.Contents("isValidated") <> "Yes" Then
  do until RS1.EOF
  if (RS1("userName") = userName) And (RS1("password") = password) Then
  Session.Contents("isValidated") = "Yes"
  Session.Contents("userName") = RS1("userName") 
Exit do
  End if
  RS1.movenext
  loop
  
  RS1.Close
  set RS1 = nothing
  C1.Close
  set C1 = nothing 
  End if
  If Session.Contents("isValidated") <> "Yes" Then %>
  <script language="vbscript">
    Msgbox "You must supply a valid username and password." & Chr(10) &
 "You will now be returned to the CD-Administration Login Page.", 16, "Error"
document.write("<meta http-equiv='refresh' content='0;url=cdadminlogin.asp'>")     
</script>
    
  <%  Else   %>

(…write the page):

<% dim CS, DRV, DBQ, OC, C1, ORS, RS1, OCM 
DRV = "Driver={Microsoft Access Driver (*.mdb)}; "
DBQ = "DBQ= C:\weborders\admins.mdb;"
CS = DRV & DBQ
set C1 = server.CreateObject("ADODB.connection")
set RS1 = server.CreateObject("ADODB.recordset")
%> 

• The browser requests a page
• The server sends the script to ASP
• ASP sends the script to the script engine
• The script engine executes the script
• The server sends the page to the browser
• The browser renders the page

The following simple login application will demonstrate how server-side code can be logically integrated with client-side code. Remember that server-side code is not executed in the browser; it is compiled and executed on the server. Therefore, it is not even visible to the client.

First, it is important to note that there is an order of operations in play with code execution. There are two types of server-side scripting methods in ASP; inline scripting and block scripting. Block scripting is indicated by script tags, like client side code, and the only difference is the addition of the "runat" attribute being included in the declaration:

<script language = "vbscript" runat = "server">
response.write "<b>Block script example</b>"
</script>
Inline script code is enclosed within "<% …. %>", the inline script tags:
<%
= "<b>Inline script example</b>"
%>

<script language = "vbscript">
document.write "<b>Client side script example</b>"
</script>

There are times when it is convenient to use server-side include (SSI) files. This allows programmers to reuse code for multiple Web pages by simply including the SSI file in their ASP page. You can include headers, footers, standard logos, and even instantiate ADO objects within an SSI file. I have always used a ".inc" extension for my SSI files, but you can use an ASP extension as well. To call the SSI file from your ASP page, you use the absolute or relative path to the file with an include statement. I normally keep the .inc file in the same directory as my application, so the files remain compact and are easy to relocate to another server if required at some future time.

Let's look at page 1 of the following application. I created this to be used by sales administrators for online company information requests from external customers. These pages are only available via the company's intranet. We are going to look at the method for validating a username and password. The usernames and passwords are stored in a Microsoft Access database that resides in a directory on the system root drive of the server. There are no hashing algorithms for the passwords, as the pages are only available to those within the firewall; so enhanced security was not a consideration. A basic means by which to prevent users from simply browsing to the actual list of submitted orders was the requirement. It provides a perfect example of server-/client-side code integration, with the conditions being established via ADO-generated data validation. The first page below will retrieve the username and password for processing by the ASP engine. Notice that all code relevant to our discussion is in red:

<!--#include file="adovbs.inc"-->
<% 
  Response.Buffer = "true"  
%> 

<html>

<head>
  <title>CD-Request Orders Login Page</title>
  <link rel="stylesheet" href="colours.css" type="text/css">
 </head>
 <TABLE CELLPADDING="0" CELLSPACING="0" BORDER="0"
 WIDTH="800">
<tr>
   <TD HEIGHT="90" width="800"
 ALIGN="LEFT"> <img src="images/company.gif"><font
 face="arial, helvetica" color="#003366"><b>CD-Request Order List
 Administration Login</b></font></TD>
   </tr>
</TABLE><br><body>
  <form action="cdorders.asp" method="POST"
 id="form1" name="form1">
  <TABLE CELLPADDING="0" CELLSPACING="0" BORDER="0"
 WIDTH="30%" align="center">
  <tr><td width="15%"><center>Username:</center></td><td
 width="50%"><input type="text"
 name="txtUserName"></td></tr>
  <tr><td width="15%"><center>Password:</center></td><td
 width="50%"><input type="password"
 name="txtPassword"></td></tr><br></table><br>
  <TABLE CELLPADDING="0" CELLSPACING="0" BORDER="0"
 WIDTH="50%" align="center">
   <tr bgcolor="#e6e6e6"><td>     
      <font face="arial, helvetica" size="2"
 color="red"><center>Please enter your username and
 password above. Click Login to validate your entry.<br>
      <input type="submit"
 name="btnSubmit" value="Login" BORDER="0" width="30" height="10">
       </font><br>
      </center></td></tr>
     </table> 
  
  </body>
  </form>
  <script language="javascript">
   document.form1.txtUserName.focus();
  </script>
  </html>

Next, the key element of this page is the "form" tag, its "action" parameter, its "method" parameter and its "name" parameter. The "action" parameter points to the next page in the ASP application. This is how ASP pages are tied together to create an application. The "method" parameter set to "post" will send the names and values of the form fields within the TCP/IP packet. The post method will not be available in the location bar of the browser and is therefore the preferred method for sending form information to the server.

Take note of the names of the fields that are used to store the username and password information. The "request" object of the page specified by the "action" parameter to retrieve their values will use these field names in processing their validity.

Finally, we see the code that creates the button to initiate the ASP application. The input type is "Submit." This is required to begin the application. An input type of button can be used, but would require otherwise unnecessary parameters. Also note that the client-side script to set the cursor to the username field is written in JavaScript. It is often preferred to use JavaScript for client-side scripting when possible, as it is compatible with a wider host of browsers than VBscript.

Tomorrow, we will examine the ASP file that processes this form information, which brings us to the meat and potatoes of the application.
Posted by Andrew Young Server-side scripting: An ASP overview
12 SEP 2005 06:58 EDT (10:58, GMT)
Hello, and thanks to all whom have taken the time to submit questions already. If you do not see an answer to your question within a day or so, it is likely I am testing the answer that I am providing prior to actually offering it as a solution. Almost 100% of what I do is geared toward business solutions, not research or study. So if I encounter questions that pertain to solutions that have not arisen in my own endeavors, I will construct the best possible answer that I can and post it at that time when I know it is accurate. I am looking forward to increasing my own experience based upon your questions.

Let me begin my time here with a little history. I was first introduced to ASP in September of 2001, when it became the core technology of my last undergraduate CS class. While I was excited about the class, I did not have high expectations, as the perception of Web development at the time among our professors was somewhat negative. They viewed Web coding as a novice form of development, and, of course, this perception filtered down to us, the students. But after enduring almost four years of some very dry (but, in retrospect, very necessary) CS concepts practiced in C++ using a VI text editor, I, for one, was open to change. This turned out to be one of the most productive classes I have ever taken. I immediately realized the great potential of ASP:

• To be able to maintain a consistent state between a client and server via a browser,
• To create multi-page applications to run via the browser with the ability to read from, and write to, external data sources via ADO and
• To compose dynamic e-mail messages via CDONTS.

I have since learned that the term ASP is a catch-all phrase. It basically refers to pages that contain server-side scripts, but it is commonly used to refer to server-side scripting technology as a whole. An ASP application consists of multiple ASP pages and includes a global application file called "global.asa." This file defines the application and allows you to tie the pages together so that information can be shared across them. This concept has not changed with ASP.NET, but it has evolved. Basically, ASP.NET consists of the same file components, with an "x" appended to them. For example, the "global.asa" file is now "global.asax".

ASP technology also has many built-in objects. They are referred to as the "ASP Object Model," which consists of the Request, Response, Session, Application, Server and ASPError objects. The ASP Object Model consists of server-side entities, as opposed to the Document Object Model (see illustration below), which is a client-side entity. You can, however, integrate your client-side scripts with built-in objects from the ASP Object Model, which we will look at with some later examples.

I think it is best to begin with the basics on this blog, for those who may be new to this technology, and introduce more advanced concepts as the time progresses. With the standard ASP topic, I will talk about scripting languages on the server and on the client with an emphasis on their integration, accompanied by the topics that arise from that discussion. When we get into ASP.NET, I will be discussing the technology in a slightly different way, as the Visual Studio.NET platform becomes a major topic of the discussion. We will start with basics, like creating an ASP.NET Web form, debugging, accessing relational data and finally reading, writing, creating and consuming XML data and Web services with a very cool example I hope to present if I can obtain permission.

The default scripting language is VB script. I formed a habit during the undergraduate learning process mentioned previously: I am most comfortable writing code in Notepad, as my first and most extensive code endeavors were done using a Unix text editor, which is very similar (in that you start with a complete blank). When I discovered Visual InterDev of Visual Studio 6.0, I found an IDE that allowed me to maintain that habit with the addition of automatic color-coding for my script tags, be it block tags, HTML tags or inline script tags. Yes, rapid application development was not exactly being fulfilled, but I was writing every line of code, and I somewhat like it that way. I have used third-party tools such as Dreamweaver and FrontPage, but I found when I looked at the code being generated in HTML, hundreds of lines were being created that were altogether unnecessary for my purposes. And they sometimes generated page errors. Not to mention, there were no front-end UI tools that helped me to create back-end connections to external data sources (i.e., instantiate calls to ADO objects). I think many developers can identify with one another in that we do not like to fix things that are not broken, especially in the software development methods that we have learned to trust.

I am primarily a Lotus/Domino developer, with advanced application certification in both R5 and Domino 6. My advanced certification is based upon LotusScript, which is altogether similar to VB script. When I saw VB script for the first time during that semester, I felt immediately at home. I also realized that I could use my object-oriented programming background (data hiding, encapsulation) in this context. Most developers agree that if you can thoroughly grasp one language -- especially C++ and its stringent use of pointers, etc. -- all languages that follow are relatively easy to learn. This was certainly the case when it came to learning VB script. It is rare in the development field when all things fall into place seemingly on their own. Here I was, though, with a language I was already familiar with, a choice of simple ideas with no learning curve, a free client/server environment to work with and some projects to work on. With the next entry I will delve into actual applications and provide another illustration, this one of the ASP Object Model.

Posted by Andrew Young