In the Active Server Pages programming model, there is a wide range of functionality that is accessible to the programmer. ASP helps us to track the state of a user, dynamically generate HTML output, and take data from forms to be inserted into a database. All of this functionality makes ASP a rather complex beast. Microsoft was tasked with finding the best compromise between offering a simple programming model and providing access to all of the power that ASP provides. To do this, the functionality was grouped into a set of objects. These objects were then related together into what is known as an object model.

An object model is a representation of a set of objects and their relationships to one another. These relationships can take the form of containment, where one object is embedded inside of another. Or, they can take the form of a parent-child relationship, where one object has a set of child objects associated with it.

We will not be examining the various methods for grouping objects together in this book. What is important to us is what the objects that make up Active Server Pages are, and how they are related to each other.

Object Model Structure

Seven objects make up the core of Active Server Pages. These are known as the built-in objects. The objects are:

  • Server object
  • Application object
  • Session object
  • Request object
  • Response object
  • ObjectContext object
  • ASPError object

Each of these objects interacts with a different part of the ASP system. This chart shows how they are related to each other, and how they are related to the client and to the server.

       (Page 1)

The following chapters in the book will go into each of these objects in greater detail. They will also provide a series of basic examples that will quickly show you how to use these objects to create ASP scripts. But for now, we will just take a quick look at what each object is for.

The Server Object

The Server object is an object that provides a home to a miscellaneous ragbag of properties and methods that can be used in almost every Active Server Page. While seemingly unrelated, these methods and properties are in fact abstractions of the properties and methods provided by the web server itself. This object will allow you to do things such as:

  • Set the amount of time a script can run before an error occurs
  • Take a user-supplied string and encode it into HTML format
  • Convert a virtual path to a physical path on the server
  • Take a user-supplied string and encode it into the proper format for a Uniform Resource Locator (URL) string
  • Create an instance of an ActiveX component. You saw this earlier in the chapter with the CreateObject method of the Server object.
  • Change the course of execution by jumping to another page using the Transfer and Execute properties.

These methods and properties are provided as utility functions for you to use in your pages. They are not directly used to affect the display of the page, but they still provide valuable support in creating Active Server Pages. Chapter 11 will cover this object in greater detail.

Application Level Objects

As the web is moving from just serving up pages to providing access to dynamic information from a wide range of systems, the sites that a user may access are beginning to look more like a traditional desktop application. We touched in Chapter 2 on the idea of a web application, and that all dynamically generated web sites are in fact web applications. The application object represents your site and all of its visitors.

The Application Object

Since these pages are functioning together as an application, naturally the developer would want some control over the application as a whole. This is the responsibility of the Application object. This object will be covered in detail in Chapter 8, but let’s just introduce a few things that it can do.

With this object, you can:

  • Be notified when an application is first started, so that you can perform some startup processing.
  • Be notified when an application is ending, so that you have the opportunity to perform functions to enable the application to close down cleanly.
  • Store information that can be accessed by all clients accessing the application.

There is one instance of the Application object for each web application running on the web server. There may be many clients accessing the same application. They each can get a reference to the same Application object. Next, we will look at an object that is unique to each client of an application.