|
Beginning
ASP 3.0
What is the Active Server Pages Object Model?
In this chapter, we have looked at how a physical object can
be represented by a programmatic object. This programmatic object
has all of the interfaces of the physical object, and it can
be used as an interface between an application and the physical
object itself. But what about objects that don't have a physical
counterpart?
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:
q Server object
q Application object
q Session object
q Request object
q Response object
q ObjectContext object
q 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.
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:
q Set the amount of time a script can run before an error occurs
q Take a user-supplied string and encode it into HTML format
q Convert a virtual path to a physical path on the server
q Take a user-supplied string and encode it into the proper
format for a Uniform Resource Locator (URL) string
q Create an instance of an ActiveX component. You saw this
earlier in the chapter with the CreateObject method of the Server
object.
q 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:
q Be notified when an application is first started, so that
you can perform some startup processing.
q Be notified when an application is ending, so that you have
the opportunity to perform functions to enable the application
to close down cleanly.
q 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.
The Session Object
There is one Application object for each application on the
web server. Every client accessing that application can get
a reference to it. Each of these clients opens a Session, therefore,
each of them has a reference to a unique Session object. This
object will be covered in Chapter 8, but here is a little of
what it can do. The Session object will allow you to:
q Be notified when a user session begins, so that you can take
appropriate actions for a new client.
q Be notified when a client has ended their session. This can
either be caused by a timeout or an explicit method called Abandon.
q Store information that can only be accessed by that particular
client throughout the session.
The Session object is the most powerful object for continuity
when using an application in Active Server Pages. One of the
problems that have existed in creating web-based applications
is that the connection between the client and the server is
stateless. The web server itself has no mechanism for tying
a request for a page by a client back to a previous request
for a page by the same client. This means that each request
that one client makes of a web server is treated independently
from the rest. While this allows for a very efficient and fast
web server, it makes writing applications nearly impossible.
Think of it this way. If you are writing an application using
a standard web server, then every request to the server must
carry along with it everything that you have done related to
the application up to this point. Since the web server has no
way of storing and retrieving that information, it is up to
you to provide it every time you make a request of the server.
Sounds pretty cumbersome? Well, with the Session object, Active
Server Pages allows you to store and retrieve information about
the client accessing your application. Nevertheless, this is
just to whet your appetite. Stay tuned for Chapter 8 when the
Session object will be explored in detail.
Page Scoped Objects
As we traverse our way through the object model, we now move
from the Session level down to the individual page level. When
working with pages of the application, we need to look at the
basic function of a web server.
Basically, a web server operates by receiving a request from
a client and then sending a response back to it. This request
could be for an HTML page, or it could be the data from a Form
submission that the user has made. To make our pages dynamic
in ASP, we need to take the information that has been submitted
and craft a customized response to send back to the client.
Active Server Pages provides two objects that allow you to
interact at the page scope. The information that is sent from
the client to the server is held, or encapsulated, in the Request
object. The information that the server prepares to send back
to client is encapsulated in the Response object. These two
objects are good examples of objects that have physical manifestations,
like our telephone. They are modeled on the HTTP request and
response.
The Request Object
When a web browser or other client application asks for a page
from a web server, this is called making a request. Along with
the actual page that the client wants, it can send a great deal
of information to the server as well. The Request object is
responsible for packaging up that information to make it easily
accessible to the ASP application.
The client asks the server to create an html page, by requesting
an .php script. When the server sees this request, it interprets
this type of page as an Active Server Page. All of the information
that the client is sending along with the request is then packaged
into the Request object. This information is then accessible
to the actual ASP script that is used to construct the page.
The information is categorized into five sets of information.
Since each set of information can include multiple individual
pieces of information, each set is stored as a collection. In
a collection, each piece of information is stored as a name-value
pair. We talked about name-value pairs earlier when we introduced
object properties.
The collections in the Request object will be explained in
detail in Chapter 7, but we will quickly introduce them here.
The collections hold information about:
q The values that are provided in the URL that are sent by
the client. In the URL, the client can include name-value pairs
of information after the file name. This information is stored
in the collection called QueryString.
q If the client is sending a Form request, then the values
of the form elements are stored in another collection – the
Form collection.
q The web server itself has a great deal of information about
the request, response and general information about the server
itself. These are called the HTTP Server Variables. This information
is made available as a collection as well.
q If the client is sending any cookies along with the request,
these are included in their own collection.
q In addition, if the client is sending any security certificates
to the server, then these are included in their own collection.
By using the information that is included with the request,
along with the script code in the Active Server Pages script
file, the server can dynamically generate a page for the client
to display. In order for the client to display the information,
the server needs a mechanism to relay the data back to the client.
This is the job of the Response object.
The Response Object
The primary feature of Active Server Pages is the ability to
dynamically create web pages. The basic task needed to execute
this feature is the ability to tell the client what information
to display. There are a number of different ways to shape what
the client will be displayed. The Response object exists to
provide an efficient interface to control the output to the
client.
The Response object provides the ASP script with a set of interfaces
that allow the script to control what information is being sent
back to the client. The details of the Response object will
be covered in Chapter 8. For now, we will just touch on some
of the functions that the Response object provides.
With the Response object, the ASP script can:
q Insert information into the page being sent back to the client.
q Send instructions to the browser to create cookies on the
client.
q Send the client to another page via a redirection.
q Control whether the page is sent as it is created, or whether
it is completely built and then sent at one time.
q Control the various properties of the page, such as the HTML
headers or the type of content.
These interfaces give the designer of the script the ultimate
flexibility to decide how the information is presented back
to the client.
The ObjectContext Object
The ObjectContext object helps you to develop applications out
of components. It does this by allowing you to handle transactions
from within an ASP page. A transaction is a single unit of work,
that must either succeed in its entirety or if it fails, then
must be undone completely returning the system to the state
it was before the transaction was started.
When using applications made of out of components, its common
to use transactions. If for example an action handled by a particular
component fails, then you'd want details of the failure, and
be able to take an alternative course of action. If a user tried
to change details of their bank account and then bombed out
mid-track, it would be logical to want track back to what the
bank account details were previously, before trying to change
the details again or continuing on alternative course.
The second type of application that uses transactions would
be one that features data processing. If someone makes an alteration
to a database via a web page, and somebody else makes another
alteration at the same time, you need to be able to accept one
alteration, while canceling, or postponing, the other. The management
of these types of transactions was handled in IIS 4.0 and PWS
4.0 by a piece of software known as Microsoft Transaction Server
(MTS). However, with IIS5 and Windows 2000, the functionality
of MTS is now integrated directly into part of the Windows 2000
operating system known as COM +.
The ObjectContext object allows access to what is known as
MTS to start or terminate a transaction. We don't want to go
into how it does that now, that's a topic for later in this
book, but this hopefully gives you an overview of this useful
object.
The ASPError Object
The ASPError object contains details of any errors generated
by an ASP script or by the asp.dll itself. Previously, there
was no facility in ASP for storing details of errors that occurred.
The ASPError object with help from the Server.GetLastError method,
allows more complex customized handling of error messages. It
directs the user to a standard error page, or to a user-created
page depending on the option selected in MMC.
back | Contents
| Forward
|
