2.2.3- Server-Side Scripting

by NT Community Manager.
Last Updated by Jim Minatel.

Public Categorized as 02. Server-Side Scripting and Client-Side Scripting.

Not tagged.

<< 2.2.2- Server-Side Scripting and Client-Side Scripting

Server-Side Scripting

As you've probably gathered by now, ASP is server-side scripting. However, it's not true to say that all server-side scripting is ASP – as we'll see in this section.

Writing Server-Side Scripts

If we're going to place any kind of server-side script within our web page source files, then we need to label the scripts – so that the server can identify them as server-side scripts and hence arrange for them to be interpreted correctly. There are two ways to label server-side scripts:

Use the <% … %> server script delimiters, which denote ASP code
Use the HTML <SCRIPT> tag, specifying the RUNAT=SERVER attribute within the tag. If a tag like this is found within an .asp file, then it is treated as ASP. If such a tag is found within an .htm file, then it is treated as a non-ASP server-side script.

We must highlight an important difference here: namely, that the choice of .htm or .asp for the suffix of your web page file is not trivial – it really does have a bearing on how your code is processed. If you have any ASP at all, you can label it using either of the techniques used above. However, in order to ensure that it's processed as ASP, then it must be included as part of an .asp file.

Within an .htm file, it's only possible to use the <SCRIPT> … </SCRIPT> tags – script contained within these tags will be interpreted as non-ASP scripts. If you try to include any ASP script within these tags, or if you write <% … %> tags into an .htm file, then the script will not be executed and your web page won't look the way you intended.

Some Samples Using the HTML <SCRIPT> Tag

So, with all that under our belt, let's look at a sample using RUNAT=SERVER first:

...

... VBScript code goes here

</SCRIPT>

...

In this first snippet, the <SCRIPT> tag specifies the scripting language that's been used for this script, and also indicates the target script host – the web server. The default (when using the <SCRIPT> tag) is for the script to be executed on the browser, so if you're writing a server-side script then you must specify this. By specifying the attribute of RUNAT as SERVER, we're making sure that it's processed on the server.

Bear in mind that this will be treated as ASP if and only if it is contained within an .asp file. That's especially useful later, when we come to write server-side scripts which use the ASP objects. We'll focus in-depth on the ASP objects from Chapter 7.

The next sample looks rather similar:

...

... JScript code goes here

</SCRIPT>

...

The processes involved are similar to those we explained for the first sample. Notice that the script tag identifies the scripting language in which the enclosed scripts are written. You can use JScript and VBScript within the same page if you like, as long as each piece of script is contained within its own tags.

A <SCRIPT> section can be placed almost anywhere in the page. You'll often find scripts at the end of the HTML document, because that makes the code easier to read.

A Sample Using the ASP <% … %> Tags

The second method doesn't involve the <SCRIPT> tag at all, but uses the <% and %> tags in place of them. These are generally more popular – they are a lot less cumbersome, they make the code easier to read, and they make it easier to distinguish between server and client side script:

...

... ASP code goes here

...

If you remembered that the <SCRIPT> tag allowed us to specify the scripting language, you might be wondering how you can specify the LANGUAGE attribute within the <% and %> tags. Well, it's done using a special notation, which applies to all of the script on a page:

<% @LANGUAGE = VBSCRIPT %>

However, ASP takes VBScript to be the default scripting language, so you'll rarely see this line. In fact, because this book chooses VBScript rather than other scripting languages, we won't need to specify the @LANGUAGE line in our ASP code.

An Example

Now we've looked at all the possible permutations and combinations for inserting scripts, it's time to try out an example.

Try It Out – Inserting a Server-Side (ASP) Script

For our first scripting example, we'll spare you the usual Hello World. Instead, we will use script instructions to 'write' the current date to an HTML document.

1. Using your preferred HTML editor, start a new document. Type the following code into it:

<HTML>

<HEAD>

<TITLE>Writing the Current Date to the Page with ASP Script</TITLE>

</HEAD>

<H2>Date Confirmation</H2>

<P>Today's date is

Response.Write Date

</SCRIPT>

, and this is the first example in Chapter 2.

</BODY>

</HTML>

2. Save the file as DateConf1.asp in your Inetpub\wwwroot\BegASPFiles directory.

3. Open your browser, and type the address http://my_server_name/BegASP/DateConf1.asp into the address line (don't forget to specify the name of your own server machine in this URL):

As you can see it works – sort of. The page contains all the right content, but not necessarily in the right order! The date comes after the period! There's a reason for this, which we'll explain in a moment.

4. Now create a new file, called DateConf2.asp. Place the following code into this new file (note that this code is similar to the code in DateConf1.asp, except for the lines that have been highlighted):

<HTML>

<HEAD>

<TITLE>Writing the Current Date to the Page with ASP Script</TITLE>

</HEAD>

<H2>Date Confirmation</H2>

<P>Today's date is

<%Response.Write Date %>

, and this is the second example in Chapter 2.

</BODY>

</HTML>

5. Save DateConf2.asp and view this example in your browser by typing in the URL http://my_server_name/BegASP/DateConf2.asp. You should get a similar result, however this time it'll be correctly formatted (subject to the odd floating space):

Well, what's that all about then?

How It Works

The first thing to notice is that both of these examples use the .asp suffix – so that the ASP script engine processes the server-side code.

In the body of the web page, we have a combination of some pure HTML, some plain text, and a little server-side script. In the first case, we specified the following script (the highlighted lines) that we wish to be processed on the server before the page is sent to the browser:

<P>Today's date is

Response.Write Date

</SCRIPT>

, and this is the first example in Chapter 2.

As we explained earlier, the line Response.Write Date causes the date to be calculated and written to the HTML stream. But why did the date appear at the end of the page, rather than when it should have appeared after "Today's date is"?

The reason is this. When the web server finds a <SCRIPT RUNAT=SERVER> tag, it arranges for the script to be processed but it appends the resulting HTML at the end of the HTML stream. In other words, it takes no notice of the position of the <SCRIPT> tag relative to other elements of the page.

By contrast, the 'in-line' script command works perfectly when we use the ASP tags to denote it:

<P>Today's date is

<%Response.Write Date %>

, and this is the second example in Chapter 2.

There's an important lesson to be learned here. Namely, that all script tags do not have the same prevalence – some script tags are processed before others, depending on how we've identified them in the source.

We'll return to the issue of the order of execution later in this chapter.

How does IIS Handle Scripts in ASP Pages?

In the light of what we've just seen, let's look again at the process involved when a user requests an ASP page.

When it receives (by HTTP) a request for a web page, the web server first examines the file extension of the requested page. If the file extension is .asp, then the web server arranges for the ASP to be handled by the ASP script host. The ASP script host is present on the web server machine in the form of the file asp.dll, which is run by the web server itself. In fact the asp.dll can only be located on the web server machine.

You can find the file asp.dll on the hard drive of your web server machine – try looking in the directory C:\WinNT\System32\InetSrv or similar. If you can't see it, make sure you've turned the Show Hidden Files option on in Windows Explorer. Be careful that you don't alter or delete the file!

The asp.dll file ensures that all the ASP code is interpreted. In fact, asp.dll is an Internet Services Application Programming Interface (ISAPI) extension to IIS, and is compiled as a Windows dynamic link library (DLL). Though this sounds daunting, it simply means that you can access your web server's functions directly, via the asp.dll, just by writing ASP code into your pages.

Now, asp.dll is a script host, so it farms out any scripts it finds to the appropriate script engines. It sends VBScript scripts to the VBScript engine, and it sends JScript scripts to the JScript engine. It's the responsibility of each script engine to interpret these scripts, and return a string of HTML to the script host. Then, the script host pulls all this together and returns it to the IIS web server, which in turn dispatches it to the browser – contained within the HTTP response.

That's what happens if the user requested an .asp page. It's worth noting again that, if the file extension of the page is not .asp, then the web server will not use the ASP script host. Instead, the web server itself acts as the script host. So in this case, the web server takes responsibility for finding any server-side scripts, and sending them to the appropriate script engines (or to the browser) for interpretation.

Caching

Just to make your life a little bit harder, a process known as caching can further confuse the results that you get back from the web server. You may well be familiar with the process of caching on the browser. A cache is temporary storage area on your hard drive that is used by the browser to store web pages and graphics. This means that, if you browse a page that you've browsed before, the browser has the option of reading the pages from the local cache instead of connecting across the Internet to the web server.

Web servers also have caches and to save time when returning ASPs, they can cache the HTML results of previously-processed ASP scripts for immediate return. This can sometimes result in you receiving the output of a previously-processed ASP, even though you've updated it since. For example, if you amend a page and then view it in your browser, it can sometimes show old results. However, if you then try it again (perhaps by refreshing the browser) it will eventually deliver the new set of results. We touch upon caching again in Chapter 7, as one of the ASP objects makes use of it, but this is just a hint to make sure that when you run the examples you're seeing the same as our screenshots indicate.

Now, to put the notion of server-side scripting into context, let's look at what we mean by client-side scripting.

<< 2.2.2- Server-Side Scripting and Client-Side Scripting

Chapter2

2.2.4- Client-Side Scripts >>