 Contents
Definition
of Active Server Pages (ASP)
ASP is an open, compile-free application environment in which
you can combine HTML, Scripts, and reusable ActiveX
Server components to create dynamic and powerful Web-based business
solutions. Active Server Pages enables Server-side scripting for IIS
with native support for both JavaScript and VBScript.
Files created with Active Server Pages have the extension .asp.
With ASP files, you can activate your Web site using any combination of
HTML, scripting – such as JavaScript or VBScript – and components
written in any language. This means your ASP file is simply a file that
can contain any combination of HTML, scripting, and calls
to components.
Remember that ActiveX = HTML + Scripting
(JavaScript, VBscript, PerlScript, etc...) + Components.
When you make a change on the ASP file on the server, you need
only save the changes to the file – the next time the Web page is
loaded, the script will automatically be run. How does this happen? It
works because ASP technology is built directly into Microsoft
Webservers, and is thus supported on all Microsoft Webservers.
A few examples of the use of Active Server Pages with IIS:
- Put your Employee Handbook online. An added benefit is the
reduction of administrative costs when employees can access and
update their own records, such as address and health-plan benefits.
- Tie your online store to your existing inventory database and
order-processing system.
- Give every visitor to your site a personalized view of just the
information he/she seeks, and automatically flag what is new since
the last visit.
Why ASP -vs- CGIs? Because ASP runs as a service of the Webserver and
is optimized for multiple threads and multiple users. This means that
it's fast, and it's easy to implement. If you use ASP, you can separate
the design of your Web page from the nitty-gritty details of programming
access to databases and applications. This frees up the programmer to do
what he/she does best – code – and, conversely, frees the designer
to worry about just the design rather than the database.
It all works together via this technology.
An example is a form that is used to pass a ticker symbol request in
the URL to the ASP files. The first part of the ASP file calls a
component that talks to a stock-price server. Properties of this Object,
such as opening and closing price, can then be easily inserted in the
HTML. The programmer can work in any language, and need worry only about
how to talk to the stock-price server. The HTML author need know only
how to script the component, and does not care how the stock-price
server works.
Back to top
When a browser requests an ASP file from your Webserver, your
Webserver calls Active Server Pages to read through the ASP file,
executing any of the commands contained within the <%
%> delineators and sending the
resulting HTML page to the browser. An ASP file can contain any
combination of HTML, script, or Object commands.
The script can assign values to variables, request information from the
server, or combine any set of commands into procedures.
Again, ASP uses the delineators <% %>
to enclose script commands. For example, the code below sets the value
of the variable "MyFavClass" in the User Cookie to
"JavaScript."
<% Response.Cookies("MyFavClass")
= "JavaScript" %>
The scripting languages supported by ASP in turn support use of the
if - else construct. Finally, you can embed some real logic into your
HTML. For example, the following code shows how you can set the greeting
shown based upon the time of day.
Run the code
<FONT
COLOR="green">
<% var now = new Date() %>
<% if (now.getHours()
>= 0 && now.getHours()
< 12) %> Good Morning!
<% else %>
Hello!
</FONT >
I'm sure that you can think of something more interesting for your
Web site – I'd hate to have to come up with all of the clever
ideas.
Back to top
Active Server Pages provides Built-in Objects
that make it easier for you to gather information sent with a browser
request, to respond to the browser, and to store information about a
particular user, such as user-selected preferences.
Application
Object
This object is universal to all users attached to an application,
there is only one Application object for all users. The Application
object has two Events, Applicaton_OnStart and Application_OnEnd,
that fire when the user requests a page from your application and when
the administrator explicitly unloads the application using the Microsoft
Management Console respectively. The OnStart Event can be used to
initialize information needed for every aspect of the application. The
OnEnd Event can be used to do any custom cleanup work after the end of
your application. You can store any variable type (with some
limitations) with application-level scope. These variables hold the same
value for every user of the site.
Again, you can use the Application object to share information
among all users of a given application. An ASP-based application is
defined as all the .asp files in a virtual directory and its
subdirectories. Because the Application object can be shared by
more than one user, there are Lock and Unlock methods to
ensure that multiple users do not try to alter a property
simultaneously.
ObjectContext
Object
You can use the ObjectContext Object to either commit or abort
a transaction, managed by Microsoft Transaction Server (MTS),
that has been initiated by a script contained in an ASP page.
When an ASP contains the @TRANSACTION directive, the page runs
in a transaction and does not finish processing until the transaction
either succeeds completely or fails.
Request
Object
The Request Object retrieves the values that the client
browser passed to the server during an HTTP request. This includes
parameters passed from an HTML form using either the POST
method or the GET method, cookies,
and client certificates. The Request object also gives
you access to binary data sent to the server, such as file uploads.
Response
Object
You can use the Response object to send output to the client.
This includes sending information directly to the browser, redirecting
the browser to another URL, or setting cookie values.
Server
Object
The Server object provides access to methods and properties on
the server. Most of these methods and properties serve as utility
functions. The most frequently used method is the one that creates an
instance of an ActiveX component (Server.CreateObject).
Other methods apply URL or HTML encoding to strings, map virtual paths
to physical paths, and set the timeout period for a script.
Session
Object
You can use the Session object to store information needed for
a particular user-session. Variables stored in the Session
object are not discarded when the user jumps between pages in the
application; instead, these variables persist for the entire time the
user is accessing pages in your application. You can also use Session
methods to explicitly end a session and set the timeout period for an
idle session.
The Webserver automatically creates a Session object when a
Web page from the application is requested by a user who does not
already have a session. The server destroys the Session object
when the session expires or is abandoned.
The Request and Response objects contain collections (bits of
information that are accessed in the same way). Objects use methods
to do some type of procedure (if you know any object-oriented
programming language, you know already what a method is) and properties
to store any of the object's attributes (such as color, font, or size).
In contrast, components can be added at your leisure to extend
the basic functionality of ActiveX Server. Components that ship with
Active Server Pages are as follows:
- Ad Rotator:
Creates advertisement rotation on your web pages
with a schedule set by you
- Browser Capabilities:
Helps you determine which capabilities
each browser accessing your pages has – support of ActiveX controls,
frames support, and more
- Database Access:
Provides a lightweight interface for
any database supporting ODBC. These are the ActiveX Data
Objects (ADO) which are built upon OLE/DB.
- Content Linking:
Enables automatic linking of files in a
sequential manner as well as the creation of a table of contents based
on a content-linking file provided by the programmer.
- File Access Component:
Accesses disk files on your server to
store/load information
The ActiveX Data Object (ADO) and the File System Object
(FSO) are easily the two most important objects. The ADO allows us to
fully interact with Databases, while the FSO allows us to read/write
files, copy/delete/move files, read/create directories, etc...
Back to top
If you want to change the scripting language for your code, you are
presented with three different choices:
- Registry:
Change for all pages of your server
- File Level:
Change only for the
current page
- Function Level:
Set scripting
language only for a specific function
The Request object is used to get information from the user that is
passed along in an HTTP request. As I mentioned earlier, the Request and
Response objects support collections:
- ClientCertificate – to get the certification fields from
the request issued by the Web browser. The fields that you can
request are specified in the X.509 standard
- QueryString – to get text
such as a name, such as my favorite TV sitcom above
- Form –
to get data from an HTML form
- Cookies – to get the value
of application-defined cookie
- ServerVariables (Source
Code) – to get HTTP information such as the server name
The Response object is used to send information to the user. The
Response object supports only Cookies as a collection (to set
cookie values). The Response object also supports a number of properties
and methods. Properties currently supported are:
- Buffer – set to buffer page output at the server.
When this is set to true, the server will not send a response until
all of the server scripts on the current page have been processed,
or until the Flush or End method has been called.
- ContentType – to set the type of content (i.e: text/HTML,
Excel, etc.)
- Expires – sets the expiration (when the data in the
user's cache for this Web page is considered invalid) based on
minutes (i.e.: expires in 10 minutes).
- ExpiresAbsolute – allows you to set the expiration date
to an absolute date and time.
- Status – returns the status line (defined in the HTTP
specification for the server).
The following methods are supported by the Response object:
- AddHeader – Adds an HTML header with a specified value
- AppendToLog – Appends a string to the end of the
Webserver log file
- BinaryWrite – writes binary data (i.e, Excel spreadsheet
data)
- Clear – clears any buffered HTML output.
- End –stops processing of the script.
- Flush – sends all of the information in the buffer.
- Redirect – to redirect the user to a different URL
- Write – to write into the HTML stream. This can be done
by using the construct
Response.write("hello")
or the shortcut command
<% = "hello" %>
The Server object supports one property, ScriptTimeout, which allows
you to set the value for when the script processing will time out, and
the following methods:
- CreateObject – to create an
instance of a server component. This component can be any component
that you have installed on your server (such as an ActiveX ).
- HTMLEncode – to encode
the specified string in HTML.
- MapPath
– to map the current virtual path to a physical directory
structure. You can then pass that path to a component that creates
the specified directory or file on the server.
- URLEncode – applies URL encoding to a specified string.
Creating Objects
To create instances of components for use in your scripts, use the CreateObject
method, By default, each object created with this method has only page
scope. This means that it is automatically destroyed when the page is
finished. The syntax for this method is as follows:
Set fsObj = Server.CreateObject("Scripting.FileSystemObject")
or depending on the ASP version
fsObj = new ActiveXObject("Scripting.FileSystemObject");
You can extend the scope to Session or Application when you create a
property in these objects with the newly instantiated component assigned
to it. They will persist until the session or application itself is
destroyed or until you close the object yourself.
The Session object is used to store information about the current
user's Web-server session. Variables stored with this object exist as
long as the user's session is active, even if more than one application
is used. This object supports one method, Abandon, which (believe
it or not!) abandons the current Web-server session, destroying any
objects, and supports two properties, SessionID, containing the
identifier for the current session, and Timeout, specifying a
time-out value for the session. One thing to bear in mind about the
session identifier: It's not a GUID. It's only good as long as the
current Web-server session is running. If you shut down the Web-server
service, the identifiers will start all over again. So don't use it to
create logon IDs, or you'll have a bunch of duplicates and one heck of a
headache.
The Application object can store information that persists for the
entire lifetime of an application (a group of pages with a common root).
Generally, this is the whole time that the IIS server is running. This
makes it a great place to store information that has to exist for more
than one user (such as a page counter). The downside of this is that
since this object isn't created anew for each user, errors that may not
show up when the code is called once may show up when it is called
10,000 times in a row. In addition, because the Application object is
shared by all the users, threading can be a nightmare to implement.
Back to top
HTTP was designed to be a stateless protocol, which means that
you will not know whether a user has requested a page on your server
before or not. An you will not receive notification when the user leaves
your server.
So you’re wondering how to implement a shopping bag for your users?
Maintain other information about your users? As always, someone came up
with a solution – cookies. These cookies are sent to each
subsequent request. Presto – you know who is coming back to your site
and you can track specific information for him or her on your server
(like shopping bag information).
Programming cookies the normal way was a bit tricky and complicated,
and associating it with more and more user information can be a
challenge. But again, there is a solution – sessions.
Tracking User Sessions
Every time a new users hits an ActiveX Server application, a session
is created for this user to store information for and about him or her.
This information is only accessible to this user.
You can use the locker metaphor for sessions: each user gets a locker
on the server on the first request and is sent the key, a cookie (a
unique, non-continual ID). When a user comes back, he carries the key
(cookie) with him to give the server access to his user information.
When the user doesn’t come back in a given time interval, the locker
is cleared.
This brings up an interesting point: We don’t know when a user has
left the application entirely. The solution for this is to set a timeout
before a session is considered abandoned.
Another interesting point is that when a browser doesn’t support
cookies, no session object is created; however, the vast majority of the
browsers support cookies, so this isn’t a considerable problem.
Tracking Application State
Why would you want to track application state? There is one very good
reason: the application is shared among all sessions, so if you place
any information in the application, it’s readily available to all
sessions. Everything you store in the application is available to all
sessions, like global variables are for all functions of a module. A
nice example is the count of currently active sessions on your
application
The application object has a simple lifespan: it’s created when the
first user request any page (it must be a script page, because a simple
HTML page won’t cause the creation of the application) and is
destroyed when the Webserver is shut down.
Back to top
Processing
Client-Provided Information
Often, the main purpose of an ASP application is to get information
from the user or get information about the user. You might think of
information about the user being where the user is coming from or what
browser the user is visiting your page with. Information from the user,
however, is generally gained whenever the user submits a form inside
your application. No matter what type of information you’re interested
in, the ASP built-in Request object makes accessing that
information very easy. The Request object manages all information that
was provided by the client’s browser:
- Form data
- certificates
- cookies
- server variables
These are organized in collections; you don’t have to bother with
how to decode form data, cookies, or anything. It is all done ASP for
you!
Collections
| COLLECTION |
DESCRIPTION |
| ClientCertificates |
Contains the field of the client certificate that
are sent when connecting to secure HTTP |
| Cookies |
This collection stores all values of cookies that
are sent in an HTTP request. |
| Form |
Contains the field/value pairs that are sent on a
form POST |
| QueryString |
Contains the values that have been sent by a HTTP
GET request. This is a parsed version of the server variable
QUERY STRING. |
| ServerVariables |
Lists the values of pre-determined environment
variables. |
Where
to Find More Information on ASP
There's already a lot more information about Active Server Pages
technology readily available. The trick, of course, is knowing where to
find it and what to look for.
|
