An ASP You Can Grasp: The ABCs of Active Server Pages
Nancy Winnick Cluts
Developer Technology Engineer
Microsoft Corporation
Updated May 28, 1997
Contents
What Is an ASP File?
Is It Hard to Use?
Aw, Mom. Not Another Object Model!
Where to Find More Information on ASP
Active Server Pages 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 VBScript and Jscript.
-- Microsoft Internet Information Server Web site
That's what they say, at least. When I read that paragraph, I want to know what this means to me as a developer, whether the Active Server Pages (ASP) technology is easy to use, and, most of all, how it works. So, I took a look at the documentation, attended a couple of presentations at Tech*Ed 97, surfed the Internet, and came up with some answers about what Active Server Pages really is, the technology's complexity level, and where you can find more detailed information (lots of links!).
What Is an ASP File?
Files created with Active Server Pages have the extension .ASP. This story is an example; take a look at the address above. With ASP files, you can activate your Web site using any combination of HTML, scripting--such as JavaScript or Visual Basic® Scripting Edition (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. 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 compiled. How does this happen? It works because ASP technology is built directly into Microsoft Web servers, and is thus supported on all Microsoft Web servers: Windows NT Internet Information Server (IIS) 3.0, Windows NT Workstation, and Windows 95 Personal Web Server.
A few examples of the use of Active Server Pages with IIS 3.0:
- Put your employee handbook online, rather than printing copies that are soon obsolete. 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. I know of several administrative assistants who would love this one!
- 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 or she seeks, and automatically flag what is new since the last visit.
I know what you're thinking: "So what? I can write CGI scripts right now that will let me update information and have it reloaded next time the page is loaded." That's true, but ASP runs as a service of the Web server 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 she does best--code like crazy--and, conversely, frees the designer to worry about just the design rather than the database.
It all works together via scripting.
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
Is It Hard to Use?
I don't know about you, but whenever people start talking about doing things on the server, I start to get nervous. I think a lot about threading issues, synchronization, and generally stuff without a user interface. I assume it's going to be hard to do. Well, using ASP is about as easy as anything I've come across in years.
If you're an experienced programer, you don't even have to learn a new language to create ASP files--you can use any language that supports ActiveX scripting. If you already develop with Visual Basic, using VBScript is a snap!
Or, if you know how to author pages in HTML, you're probably ready to advance your skills a notch—and ASP is the perfect reason. Learning VBScript is not hard. Neither is JScript, Microsoft's implementation of JavaScript.
You don't even have to write your own controls to start using Active Server Pages. You can use any off-the-shelf-control that can be run on a server and has no user interface The reason it should not have a user interface becomes obvious when you picture some hapless computer operator sitting in front of the server, dismissing dialog boxes meant for the user's machine. I mean, why should the operator care whether you've logged on successfully? User interfaces are for client applications (applications that the user is running)--not for server-side scripting.
Back to top
Aw, Mom. Not Another Object Model!
I really hate doing this to you, but I'm going to have to use that overused and overcomplex term "object model" again. Here's how it works. When a browser requests an ASP file from your Web server, your Web server calls Active Server Pages to read through the ASP file, executing any of the commands contained within and sending the resulting HTML page to the browser. An ASP file can contain any combination of HTML, script, or commands. The script can assign values to variables, request information from the server, or combine any set of commands into procedures.
ASP uses the delimiters (better known to you and me as "thing-a-ma-bobs that specify the beginning and end") "<%" and "%>" to enclose script commands. For example, the code below sets the value of the variable "MyFavTVShow" in the user cookie to "I Dream of Jeannie."
<%Response.Cookies("MyFavTVShow")="I Dream of Jeannie"%>
The scripting languages supported by ASP in turn support use of the If-Then-Else construct (something that will undoubtedly warm the hearts of all coders out there). Finally, you can embed some real logic into your HTML. For example, the following code from the IIS documentation shows how you can set the greeting shown based upon the time of day.
<FONT COLOR="GREEN">
<%If Time >= #12:00:00 AM# And Time < #12:00:00 PM# Then%>
Good Morning!
<%Else%>
Hello!
<%End If%> </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.
Built-in Objects
ASP includes five standard objects for global use:
- Request—to get information from the user
- Response—to send information to the user
- Server—to control the Internet Information Server
- Session—to store information about and change settings for the user's current Web-server session
- Application—to share application-level information and control settings for the lifetime of the application
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).
The Request object
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—to get HTTP information such as the server name
The Response object
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 specificationfor 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 Web server 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
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.
The Session object
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
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.
Need Help?
Remember, NorthStar Web Design account development managers are here to help you with any of these items.
