Getting Started with ASP

The Web has grown beyond the point where an online brochure will satisfy a typical company’s needs for its Web presence. If you aim to market yourself as a Webmaster these days, you need to have some skill building online applications – Web sites that users can interact with, whether to get something done (e.g. send email), get information targeted to their specific needs (e.g. a real-time stock quote), or to interact with other users (e.g. an online community).

In this series of articles, I’ll guide you through the process of learning one of the most popular frameworks for creating dynamic Web sites such as these – Active Server Pages (ASP). If you can secure a strong knowledge of ASP, as well as some practical experience building Web sites with it, you should never have trouble getting work as a Web developer. A quick search of your favourite online job directory with the keyword ‘ASP’ should be more than enough to convince you of that.

In this first article, I’ll help you get your feet wet by introducing the VBScript programming language, and how to use it to write dynamic Web pages with ASP. Before I get to that, I shall stop to explain how server-side scripting, and ASP in particular, differs from other Web scripting technologies that you may be familiar with, such as client-side JavaScript. This will get you armed with the proper vocabulary and ensure that we’re on the same page before launching headlong into the brave, new world of ASP.

Server-Side Scripting

To understand where ASP fits into the big picture of Web development, you need to understand the concept of a server-side scripting language. If you’ve programmed Web pages in Perl, PHP, JSP, or Cold Fusion before, you can safely skip this section – all of those are server-side scripting languages, and ASP works in much the same way. If you’re coming to ASP armed only with knowledge of HTML (and perhaps with some CSS and/or JavaScript experience) then you’ll find that server-side scripting is quite a bit different.

Let me begin by giving you a quick review of how standard, non-ASP Web pages work. As shown in Figure 1, the Web browser on the client computer (the computer belonging to the user) makes a request for a page, say file.html (1). Assuming the requested file exists on the Web host computer where the Web Server software can find it, that software replies to the request by sending the file back to the browser (2). Any additional files (images, for example) required to display the page are requested and received in the same way. The protocol used for this exchange, and indeed for all communication between Web browsers and Web servers is called Hypertext Transfer Protocol (HTTP).

If you’ve ever used any JavaScript in your pages, you know that the requested Web page (file.html) can contain, in addition to plain HTML code, small programs written in JavaScript. These programs, or scripts, are read and executed by the Web browser while the page is displayed in the browser. So the Web browser must understand not only how to read HTML and display text and images, but it must also be able to run JavaScript programs appearing inside Web pages. This arrangement, where the Web browser runs the script after receiving it from the Web server, is called client-side scripting. The name makes sense – all of the script runs on the client-side – the right-hand side of Figure 1. The Web server is completely oblivious to whether the file it is sending contains a script or not; it’s all up to the browser (the client) to handle execution of the script.

ASP fits into a different category of technologies, called server-side scripting, where it is no longer the browser running on the client that is responsible for running the script; instead, it is the Web server that runs the script. This process is illustrated in Figure 2. As before, the Web browser requests a file (1). In this case, however, the filename ends with .asp (file.asp, for example), branding it as a file containing an ASP script that needs to be processed by the server. The server recognizes this, and instead of directly sending the requested file back to the browser, it sends the file to the ASP scripting engine (2). The engine is a component of the Web server software that can interpret ASP scripts and output the results as HTML. The trick here is that any given script can output different HTML each time it is run, so what comes out of the ASP engine can be different for each client (browser) request. That dynamically generated page is then sent to the browser in response to its request (3), in exactly the same way as the static page was sent in the previous example.

Just as when the page contained client-side JavaScript and the server was completely unaware of this fact, when the page contains server-side ASP script, the browser does not know this at all. The ASP code contained in the page is interpreted and converted to plain HTML by the ASP engine before the browser gets to see it; so as far as the browser is concerned an ASP page looks just like any normal Web page. All the work is done on the server-side; thus the name, server-side scripting!

Setting Up an ASP Server

As I have just shown, the Web server that houses your Web site must be equipped with an ASP scripting engine to be able to process ASP pages. Most free Web servers (GeoCities, Xoom, etc.) do not provide this type of service, or charge for it if they do. If you’re not ready to shell out for a Web host that will provide you with ASP support, or if you simply want to follow along and learn ASP for the time being without publishing an actual Web site on the Internet, then there is another option.

By installing Web server software on your own computer, you can then request ASP pages in your browser and have your own server software interpret the ASP scripts. As illustrated in Figure 3, this set-up places the Web client and server on the same computer. While the Internet at large will not be able to access this server to request Web pages (unless you equip your computer with a permanent Internet connection and a fixed Web address), this will allow you to develop and test ASP scripts on your own computer without spending money for a Web host or maintaining an Internet connection to view your pages.

If you do have a Web host that provides ASP support, or if you’ve been able to set up an ASP-capable Web server on your own computer already, feel free to skip the remainder of this section.

When it comes to choosing Web server software, the choices available to you – even if you restrict your search to free programs – can be quite bewildering. Our requirement that the server contain an ASP engine does narrow the field considerably, however. The ideal Web server for ASP development is Microsoft Internet Information Server (IIS) 5.0. This server comes free with every copy of Windows 2000; thus, you’re set if you have access to a computer running Windows 2000. Otherwise, you’ll have to look into one of the alternatives I discuss below, or bite the bullet and sign up with a Web host that provides ASP support.

Installing IIS 5.0 on Windows 2000 is really quite easy. Just open Control Panel and run Add/Remove Programs. Click on Add/Remove Windows Components, and wait for the Windows Components Wizard to appear. In the list of components, you should see Internet Information Services (IIS). Make sure this is checked, and click on the Details… button if you wish to configure which individual components get installed (you’ll definitely want the Documentation, for example, but you’re unlikely to need the SMTP Service). When you’re done, follow the instructions to complete installation. You may need to have your Windows 2000 CD on hand.

If you don’t have Windows 2000 to work with, there are other options. For Windows 95/98/Me/NT computers, you can install the Windows NT 4.0 Option Pack (yes, even if you’re running Windows 9x). The Option Pack is available here: Download the Windows NT 4.0 Option Pack. Under Windows NT Server, the Option Pack will install Microsoft IIS 4.0, while under Windows 95/98/Me and NT Workstation it will install Microsoft Personal Web Server (PWS) 4.0, a scaled-down version of IIS 4.0. Both of these servers feature built-in ASP engines, but those engines only support ASP 2.0, while IIS 5.0 supports the newer ASP 3.0. Most of the techniques I’ll be presenting in this series will work equally well in both versions of ASP; however, some of the more advanced features of the language are only available in the newer version, and ASP 3.0 provides more helpful error messages when things go awry. For these reasons, you should try to secure a server with ASP 3.0 capabilities if it is feasible to do so.

If you are unable or unwilling to run your Web server under a Windows-based operating system, all is not lost. There are several commercial options for adding ASP support to servers such as Apache (ChiliSoft ASP, for one); however, such set-ups are far from ideal for learning ASP, since many components of Microsoft’s original ASP framework rely heavily on features of Windows, those components will be altered or missing entirely from platform-independent versions of ASP.

With your ASP-equipped Web server software installed on your computer or provided by your Web host, your first step should be to write a simple ASP script to check that everything is working properly.

Your First Script

You should begin by making sure your Web server is operating properly by putting up a simple Web page and viewing it using your browser. If you’ll be using a Web host for your ASP development, then you are probably familiar with the steps involved. Typically you must use an FTP program to put the Web page on your Web host’s server, and then you can access it with your Web browser by typing the address (e.g. http://www.mywebsite.com/testing.html).

If you’ve installed Web server software on your own computer, a similar process is involved. Instead of sending the file to the server via FTP, however, you just have to place the file you want to make available in the directory your Web server expects. Microsoft IIS and PWS both default to using C:Inetpubwwwroot. Once a file has been placed in that directory, you can view it by opening your Web browser and typing the address http://localhost/file.html, where file.html is the name of the file that you placed in the directory.

Note that placing the file in the appropriate directory and using the above address is very different from just using the “File | Open…” menu command in your browser to view the file directly off your hard drive. By typing the address, you are instructing the browser to request the file from the Web server running on your computer. This gives the server software a chance to process any ASP scripts that the Web page might contain. If you open the file directly using “File | Open…”, or by typing the path and filename (i.e. C:Inetpubwwwrootfile.html) into the address field, the server doesn’t get a crack at the file first, and server-side scripts will not be processed. That’s why it’s important that you always open ASP pages on your computer using the http://localhost/ address.

Now, assuming you’re able to put a basic HTML Web page on your server and view it as described above, you should now be ready to try your hand at writing and viewing an ASP script. Open Notepad, or whatever text editor you prefer (programs like UltraEdit, HotDog Professional, HomeSite, and Visual Studio all provide convenient support for highlighting of ASP code, among other features), and type the following code:

<html>

<head>

<title> My First ASP Page </title>

</head>

<body>

<%

' Write out a simple HTML paragraph

Response.Write "<p>This is a test of ASP.</p>"

%>

</body>

</html>

If you’re thinking this code looks remarkably like an HTML file, you’ve got the right idea. Save the file as asptest.asp. In Notepad you’ll need to either select “All Files” in the “Save as type” drop-down menu or enclose the filename in double quotes ("asptest.asp") to avoid having your file renamed to asptest.asp.txt. If you’re working with a Web host, upload the file to your account using FTP, or whatever alternative method your host provides. If you’re working with server software running on your own computer, copy the file to the Web root folder of the server (C:Inetpubwwwroot for IIS or PWS).

Now, try viewing the ASP page in your Web browser by typing its address. This should be something like http://www.mywebsite.com/asptest.asp if you placed the file on a Web host, or http://localhost/asptest.asp if you’re working with a server running on your own computer.

What you should see is a Web page containing the words "This is a test of ASP." much like that shown above. If instead you get a blank page, chances are good that your Web server did not process the ASP code. Try the “View Source” function of your Web browser. If the code of the page appears exactly as you entered it above, then there is definitely something wrong. Remember, the ASP scripting engine in the Web server is supposed to process the ASP code and convert it to plain HTML before sending it to the Web browser. In fact, if everything works like it’s supposed to, you should see the following code when you use “View Source”:

<html>

<head>

<title> My First ASP Page </title>

</head>

<body>

<p>This is a test of ASP.</p>

</body>

</html>

Notice how the ASP code, which began with <% and ended with %> has been replaced with the HTML code for a simple paragraph of text. If this isn’t happening, then either you’re not viewing the page through your Web server (that is, you used “File | Open…” to open the page in your browser, as I warned you not to), or your Web server’s ASP support is not working (or is non-existent). If after reviewing these possibilities you’re still stuck with a test page that isn’t working properly, post your question in the SitePoint Community Forums, or email me directly and I’ll assist you as my schedule permits (generally, you’ll get a much quicker response from the forum community).

How It Works

Assuming you’ve got your ASP test page working, you’re probably curious to know how it works. Well, as you no doubt guessed, the first five lines of the file are just plain HTML.

<html>

<head>

<title> My First ASP Page </title>

</head>

<body>

One of the most convenient aspects of ASP (and, indeed, most server-side scripting languages in use today) is that it lets you intersperse your script code with plain HTML. The script code gets processed, while the plain HTML gets sent as-is (with a few notable exceptions that you’ll see later on).

The next line marks the beginning of the actual ASP code in this page.

<%

Every block of ASP code must begin with a start marker (<%). This is what lets the ASP scripting engine know that it should start converting ASP code into HTML. This marker doesn’t necessarily have to appear on a line by itself; as I’ll show in later examples, a block of ASP code, markers and all, can in fact appear right in the middle of a single HTML tag on a single line. In this case, I’ve placed the marker on a separate line to make it stand out more.

The next line actually doesn’t do anything:

' Write out a simple HTML paragraph

This line is what programmers call a comment. The apostrophe at the start of the line marks the rest of the line as something for the ASP scripting engine to ignore. To the script, this line is utterly without function, and if you removed it or changed it in any way (except for the apostrophe) you would not affect how the script worked at all. Nevertheless, it is good programming practice to intersperse little explanatory remarks such as this in your code for the benefit of anyone who needs to read and understand your code later on (including yourself!).

A comment need not appear on a line by itself. As soon as it sees an apostrophe, the ASP engine will ignore the remainder of the line on which it appears, so you can just as well place a comment on the end of a line, following the command to which it pertains.

Speaking of commands, the next line is the first and only ASP command in the script:

Response.Write "<p>This is a test of ASP.</p>"

In simple terms, an ASP command, or statement, is a piece of code that tells the ASP scripting engine to do something. By listing a series of statements one after another in the order you want them to be completed, you can write an ASP script that does any number of things in the specified order. In this case, however, I only needed the script to do one thing: write out the HTML code necessary to produce a paragraph of text that reads, “This is a test of ASP.”

The code Response.Write is ASP’s way of saying, “write the following into the Web page.” The HTML code to be written then follows, enclosed in double quotes to mark the start and end of the string of text to be written (any portion of text in ASP is called a text string).

Having finished telling ASP what to do, I ended the ASP code block with the ending marker, (%>). Like the starting marker (<%) above, the ending marker serves to indicate the boundary between normal HTML code and ASP script commands. When it sees an ending marker, the ASP scripting engine goes back to just sending the HTML code as typed.

%>

To finish off the page, I added the familiar closing tags:

</body>

</html>

And there you have it! With this guided tour of a simple ASP script under your belt, you should at least be able to point to each line in your asptest.asp file and explain what it does (or, in the case of the comment line, what it doesn’t!). You may be asking a very sensible question, however: “Isn’t that just a long-winded way of creating a plain, old HTML page?”

Well you’re partly right. Certainly, every person who viewed asptest.asp would just see that simple one-liner. But the magic is in how that one-liner came about. It is re-created dynamically every time someone requests the page. It’s not ASP’s fault that you supplied it with code that will produce the exact same output every time it is run. Actually it’s my fault. Allow me to remedy that situation by altering the code of your asptest.asp file to read as follows:

<html>

<head>

<title> Time Check </title>

</head>

<body>

<%

' Write out a the current server time

Response.Write "<p>The server time is now: "

Response.Write Time

Response.Write "</p>"

%>

</body>

</html>

Save the changes, and then place the updated file on your Web server. When you view the page in your browser now, you should see something like this:

Notice that when you refresh your browser, the time is updated to match the time according to the computer on which the Web server is running. Notice also that when you use the “View Source” command in your browser, all you see is plain HTML code. ASP writes the time into the page before sending it to the browser. Net result: a dynamic Web page, albeit a very simple one.

The only new trick in this page is the use of the special word, Time, on line 9. Since this word isn’t surrounded by double quotes, ASP knows that it isn’t supposed to just print out the word “Time.” Instead, ASP knows that the word Time should be replaced with a string of text representing the current time (e.g. “5:32:45 PM”), and so that’s what the Response.Write command prints out. You’ll learn other special ASP words like Time later on in this series.

Notice also that this new script contains three ASP statements, each of which is a Response.Write command. These are executed in the order they appear, from top to bottom, producing the desired HTML code.

Wrap-Up

With this article, you’ve taken your first steps into the world of ASP. The next article to follow in this series will cover everything you need to know about the VBScript language, which is the primary language used for writing ASP scripts (you can use JavaScript as well). After that, you’ll be ready to tackle the subject of building Web applications that access databases and other server-side resources in ASP, all of which will be covered in upcoming instalments of this series.

If you’re in a hurry to move forward, however, the ASP documentation accompanying Microsoft IIS and PWS, in combination with the VBScript documentation at the Microsoft Scripting Technologies Web site are fairly well written and should help you on your way. If the documentation is too cryptic for your tastes, you might find a book like “Beginning ASP 3.0” from WROX Press helpful.

Good luck, and I hope to see you back soon for part two of this series!