If you are new to the whole scripting scene and don’t have any kind of programming experience behind you, then Active Server Pages (ASP) is probably one of the easiest ways to start in the world of web application development. This article provides a quick overview to help you get an idea of how the technology works and if it is for you.
Active Server Pages was a technology introduced by Microsoft in Internet Information Server 2.0. Code named Denali, the technology uses a small Internet Server Programming Application Interface filter (ISAPI Filter) that loads any required scripting language interpreters when a user first requests an ASP page. Because the filter is in memory for as long as the server is running, there is no additional overhead of starting new processes and so it is thought to be much kinder on server resources than the traditional CGI applications.
How ASP works
When an ASP page is requested, the ASP ISAPI filter executes any server side code it finds in the page before sending back a more browser friendly response. Normally this is HTML, but can be HTML with embedded scripts, images or any other file type so long as the correct headers are sent along with the response.
The response an ASP page gives to a request can be manipulated by the use of ASP objects, each have their own properties and methods that can be manipulated by any scripting language that has been configured to run with the server (typically VBScript).
The ASP objects listed above are of little use on their own, you will need to be familiar with at least one scripting language before you can start to build your own pages that use these objects. VBScript is the common choice, not only is it the default scripting language that is assumed for ASP pages, but it is the scripting language that is most like English.
The Application object is one that represents the whole domain space, without it ASP will not work. Before ASP can work, you have to create the application; this tells the server to load the ASP ISAPI filter for the files in that particular space. The application object will then run in the background on the server until it is stopped or restarted.
Any variables that you store in the application will be available to all your ASP pages, and so this is an easy way to pass data from one script to another. However it does use system resources (such as memory) and so the use of application level variables is not very efficient and can in some cases slow down your site.
The objectcontext object allows you to create and run transactions. The best way to describe a transaction is a piece of code that can be undone should there be problems.
The response object will send the results of any server side scripts back to the user’s browser. It has methods to add headers telling the browser when to expire the page, what character set to use and can even detect if the connection originally used to request the page has been closed. This can be a handy feature as it can stop scripts when there is no one there to see the page, thus saving data transfer and server resources.
Not only does the response object control what gets sent back to the browser, but also how it gets sent back. It is possible to buffer the response and send it back when the whole script is finished, or you could send the data back in chunks to let your visitors know that it is still working.
The request object holds all the information that has been sent from the user that can be used in your scripts. This includes any page headers, cookies, form or URL data. Fortunately, all this data has been parsed to some degree and so you don’t need to worry about breaking it all down and putting it back together again; just remember to make sure that it is safe to use!
The server object is mainly used as a utility object; helping create new instances of add-in ASP objects, find the real path of a file and converting output to make it more browser friendly. It can also be used to set the server time out response, which is handy for scripts that need a longer time to execute without sending any output to the browser.
The session object works a little like the application object, but is specific to the user and the browser they are using. It can make a viable alternative to cookies used to store and move data between scripts, but as sessions tend to expire very quickly (usually 20 minutes after last activity) they can only store data temporarily.
Expanding ASP Capabilities
There are other objects that are additional to the built in objects listed above that can be used to provide additional functionality.
- FileSystemObject – allows ASP pages to interact directly with files stored anywhere on the host server (which is why a few hosts have this disabled). This is a useful object; Web Site Owner relies on it to create the pages.
- CDONTS (Collaboration Data Objects for Windows NT Server) – used to send and receive messages, this object is Microsoft’s offering of adding mail capabilities to a site. As the name suggests, it is a little dated now and most of the hosts I’ve asked tend to prefer other 3rd party objects to do the same job; JMail and ASPEmail being two prefererred replacements.
- ADO (ActiveX Data Objects) – used to interact with databases (either physical or those created in working memory).
ASP may not be as fast as some of the scripting languages available today, but it is the easiest for a beginner to learn and with a little imagination and a logical mind it can do a wide variety of things.
The author, Rosemarie Wise, is a self proclaimed “web enthusiast” who set up her site, Web Site Owner to share her experiences of being a site owner.