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!