2.2.4- Client-Side Scripts

<< 2.2.3- Server-Side Scripting

Chapter2

2.3.0- The Order of Execution >>

Client-Side Scripts

Client-side scripting is not directly related to ASP at all – it involves writing scripts that will be processed by the browser. When a web page source contains a client-side script, it does not attempt to process the script; instead, it simply downloads the script to the browser as part of the HTTP response, and assumes that the browser will know how to deal with it.

When the browser receives the HTTP response, it needs to process the HTML contained within, which describes how it is to display the page. The browser must also take care of the client-side scripts that were downloaded as part of the page.

Advantages and Disadvantages

As you might expect, the main advantage of client-side scripting over pure HTML is that it allows the developer to create more functional, interactive web pages. There are two clear advantages of client-side scripting over server-side scripting. First, the response times are often quicker, because the script is interpreted on the browser machine – so there is no network involved. This is a big advantage for repeated calculations because there's no round-trip to ask the server to calculate things. Second, executing script on the browser means that there's less script to be executed on the web server; reducing the web server's workload can be advantageous if lots of people use your web site.

 

However, when weighing up the choice between client-side and server-side scripting, you must also consider the disadvantages. The main disadvantage of client-side scripting is that we can't depend on the browser having the functionality to support the scripts we write. If you have two different client machines that host two different browsers, and you view a page that contains a client-side script on each, then you can reasonably expect the results to be quite different.

 

In other words, client-side scripting is browser specific – because some browsers do not have the capability to interpret certain scripting languages. For example:

 

• Recent versions of Internet Explorer come with script engines for both VBScript and for JScript – although older versions of the browser come by default with older versions of the scripting engines.
• Netscape Navigator browsers come with a JavaScript script engine only - there is no support for VBScript. So, at best, any client-side VBScript in your page does not look quite as intended – and at worst, it'll cause an error message.

It is possible to allow Netscape browsers to view the results of client-side VBScript – but it requires a manually-installed third party add-in on the client machine.

You'll find that JScript (or JavaScript) tends to be the language of choice on the web, as far as client-side coding is concerned. This has been further reinforced by the adoption of JavaScript as a standard, maintained by ECMA (European Computer Manufacturer's Standards) and known as ECMAScript – which sets a bottom line that both JScript and JavaScript can adhere to.

 

Another potential disadvantage of client-side scripting is that the code in your client-side scripts is completely visible to the user. Remember how we used the View | Source option in Internet Explorer, or the View | Page Source option on Netscape Navigator, to view the HTML source for the web page? Well, it also displays the code for any client-side scripts that were downloaded from the web server. So, if you want to keep your client-side script code a secret then you'll have to use complex encryption techniques – otherwise client-side scripting is not an option!

Writing Client-Side Scripts

As we now know, the HTTP response that is sent to the browser includes some pure HTML and some non-HTML code (that is, client-side script). In order to display the page, the browser first sends the client-side script to the appropriate script host on the client machine for interpretation; and it processes all of the HTML code itself.

 

So the browser, like the web server before it, needs to be able to look at the source and make a distinction between the pure HTML and the client script code. Once again, it is the HTML <SCRIPT> tags that allow this. If the browser detects a pair of <SCRIPT> and </SCRIPT> tags in the source, it assumes that anything that lies in between is script.

 

In order to illustrate this, we need a few samples. The following few snippets are fragments of HTML source files. Here's the first sample:

 

...

<SCRIPT LANGUAGE=VBSCRIPT>

  ... VBScript code goes here

</SCRIPT>

...

 

This code looks much like the samples we saw when we were discussing server-side scripts. There's one significant difference – we haven't specified the RUNAT attribute. Unless we specify otherwise, any scripts contained within the HTML <SCRIPT> … </SCRIPT> tags are assumed to be client-side scripts; so in fact, this code fragment is equivalent to the following:

 

...

<SCRIPT LANGUAGE=VBSCRIPT RUNAT=CLIENT>

  ... VBScript code goes here

</SCRIPT>

...

 

Note that if you were to include code like this in a page, it must be saved as a .htm or .html page, and must not have the suffix .asp (because the RUNAT=CLIENT expression will cause an error). To run a script on the client side, you can completely omit the RUNAT attribute. For example, if we wanted to write a client-side script using JavaScript, we could use the following:

 

...

<SCRIPT LANGUAGE=JAVASCRIPT>

  ... JavaScript code goes here

</SCRIPT>

...

 

Again, you can write a page that contains both JavaScript scripts and VBScript scripts – you need to use a new <SCRIPT> tag for each new script. And again, each <SCRIPT> section can be placed almost anywhere in the page. In client-side scripting, some authors prefer to place most of their scripts at the end of the HTML document, so that the rest of the page can be loaded and rendered by the browser before the interpreter loads and runs the code. In this way, the whole of the page can be loaded first – instead of having to wait while alternate chunks of HTML and script are processed. Of course, if we were using 'in-line' scripts to write something into a particular position in the page, then we'd need to place the <SCRIPT> section at the appropriate position in relation to the surrounding HTML:

 

...

The local time in Browserland is exactly

<SCRIPT LANGUAGE=VBSCRIPT> Document.Write Time</SCRIPT>

<P>

...

 

In this snippet, the browser must execute the Time function (which is a VBScript function) and pass the result to the Write method of something called the Document object. The Write method writes the information into the page at the point where it's called, so the result is something like this (don't worry about typing this example in – we'll give you a full working one very shortly):

 

Don't worry – you're not expected to know about methods and objects just yet! In particular, the Document object is not of great importance to us in this book –  all you need to know is that it is part of the browser (it's not an ASP object) and that it allows client-side scripts to write information on the web page.

 

Before we move on, you might like to compare the code above with the equivalent line in the Punctual Web Server example, from Chapter 1 , in which we used the ASP <% … %> tags to create a server-side script, and displayed the time as calculated by the web server:

 

  In Webserverland, the time is exactly <% = Time %>

Comment Tags

As we've mentioned, successful execution of a snippet of script is dependent on whether your browser supports the requisite scripting language. What happens if you're using an older version of Navigator or Internet Explorer to browse a web page that contains script? The script will simply be displayed as text on the web page, which is all very messy and not at all what you'd want to happen.

 

So, the traditional way to prevent the code from being displayed as part of the page is to enclose the contents of the <SCRIPT> section within a pair of comment tags. If the user's browser is not script enabled, then it will ignore any code contained within comment tags; while browsers that do support scripting will still be able to interpret and execute the script. (If, for example, we have a browser that only supports JavaScript, then the comments will allow any VBScript to be ignored.) Here's how we'd add comment tags to the above code fragment:

 

...

The local time in Browserland is exactly

<SCRIPT LANGUAGE=VBSCRIPT>

<!-- hide from older browsers

Document.Write Time

-->

</SCRIPT>

...

In order to 'comment out' a JavaScript script, the comment tags used are slightly different (and you should be careful not to confuse them!). Here's an example: 

 

The local time in Browserland is exactly

<SCRIPT LANGUAGE=JAVASCRIPT>

<!--

d = new Date();

document.write(d);

//-->

</SCRIPT>

Notice the positioning of the comment tags <!- - … - -> or <!- - … //- ->, and in particular, that we've placed the comment tags and the script code on different lines. Placing the tags on the same line as the script code can result in some browsers being unable to interpret the enclosed script. If the opening and closing tags both appear on the same line then the whole of that line acts as a comment; if the tags appear on two separate lines, the lines containing the opening and closing tags, and the lines contained within, are all considered as comment lines.

Of course, many browsers will be able to deal with script like this – indeed support for a scripting language is pretty much a prerequisite in many of the latest versions. But if you are writing client-side scripts, consider safety first – it doesn't hurt to use comments to 'hide' client-side scripting from any older browsers that might attempt to load your page.

A Client-Side Script using VBScript

OK, now we've talked enough about client-side scripts to try out a simple example.

For our first client-side scripting example, we'll take the example that we created in server-side script and turn the script into a client-side script, which 'writes' the current date to an HTML document.

 

1.    Use your editor to create a new file, and type in the following (note that this is quite similar to DateConf1.asp – the differences are highlighted):

<HTML>

<HEAD>

<TITLE>Writing the Current Date to a Document with Client-side VBScript</TITLE>

</HEAD>

 

<BODY BGCOLOR=WHITE>

<H2>Date Confirmation</H2>

<P>Today's date is

<SCRIPT LANGUAGE=VBSCRIPT>

<!--

Document.Write Date

-->

</SCRIPT>

, and this is the third example in Chapter 2.

</BODY>

</HTML>

2.    Save the file as DateConf3.htm, in your \Inetpub\wwwroot\BegASPFiles directory. Note that we're saving it as an .htm file, not as an .asp file. That's because there isn't any ASP in this example.

3.    Open Internet Explorer, and type the address http://my_server_name/ BegASP/DateConf3.htm into the address line:

 

The HTML output shows a single sentence, containing the current date. The date is generated by the VBScript code, which is executed on the client, and is formatted in the default date format used by the client computer.

How It Works

The first thing to highlight is that we've saved this file with the suffix .htm. We could have saved it as an .asp file –and if we had, then the ASP script engine (on the web server, remember) would be called into action at the time the page is requested. However, there's no ASP code in this page so the ASP script engine would have been redundant.

 

In older versions of the IIS web server, just adding an .asp extension would actually have been enough to impede the performance of the page, because the web server would automatically send the page for processing. However, IIS 5.0 is intelligent enough to check your page for ASP code before sending it to the ASP script host; and if there's no ASP code then it won't send it for processing. There is still a small performance price to be paid for getting the page checked by the server for ASP code first anyway. But the point is this: when there's no ASP code in the page, an .htm or .html extension is normally sufficient.

 

In this case, the page consists of only text, some HTML and a client-side script – all of which are interpreted by the browser. When the browser comes across a <SCRIPT> tag, it knows that it needs to send the code to the appropriate script engine. In this example, we've specified the LANGUAGE attribute in the <SCRIPT> tag, for clarity:

 

<SCRIPT LANGUAGE=VBSCRIPT>

...

</SCRIPT>

 

This attribute indicates that the script contained within is written in VBScript and must be interpreted by a VBScript script engine.

 

The next part of the program is the VBScript itself:

 

Document.Write Date

This causes the browser's VBScript script engine to execute the built-in VBScript Date function, which returns a value containing the current date; and tells an entity known as the Document object to use its Write method to display this date value as part of the page.

 

Incidentally, the mysterious Document object is (quite literally) a representation of the HTML document or web page that is being currently displayed in the browser. However, as we said before, the Document object isn't part of ASP: it's something that is created by the browser, and is held only on the client side. You can use the Document object in Dynamic HTML to get information about the document, to analyze and modify the HTML elements and text in the document; and to process events.

We'll discuss the concept of objects more fully at the beginning of Chapter6 . We won't be looking at browser objects like Document in any detail, since they aren't part of ASP.

 

Let's see what happens if we try to run this example on a browser that doesn't support VBScript. Here's what the page looks like on Netscape Communicator 4.6.

 

 

As you can see, the browser has detected the comment tags and recognized that it can't deal with the VBScript – so it's left it out. Note also that there's no error message, so the page appears to load smoothly. If your VBScript script only performs tasks that are non-essential to the overall page (things like dynamic graphics, for example) then it ensures that the user still has a smooth ride. But if, as in this case, the VBScript performs an essential task, then we still don't get the output that we want.

A Client-Side Script using JavaScript

That's all we need to know about VBScript scripts for now. Next, we'll have a look at how to insert a JavaScript script into our code.

 

We'll reconstitute the date confirmation program once more, this time replacing the client-side VBScript with client-side JavaScript.

 

1.    Use your HTML editor to create one more new file, and add the following code. It's similar to DateConf3.htm, and the differences have been highlighted below:

<HTML>

<HEAD>

<TITLE>Writing the Current Date to a Document with Client-side JavaScript</TITLE>

</HEAD>

 

<BODY BGCOLOR=WHITE>

<H2>Date Confirmation</H2>

<P>Today's date is

<SCRIPT LANGUAGE=JAVASCRIPT RUNAT=CLIENT>

<!--

d = new Date();

document.write (d);

//-->

</SCRIPT>

, and this is the fourth example in Chapter 2.

</BODY>

</HTML>

 

In this example, take extra care to ensure that you use the correct case when typing in this example. JavaScript is case sensitive, so – for example – it will treat date and Date differently. Date is a built-in JavaScript object; however, if you try to use date then JavaScript will not recognize it, and will throw errors at you.

2.    Save the file as DateConf4.htm.

3.    Open a browser, and type the address http://my_server_name/
BegASP/DateConf4.htm into the address line:

How It Works

It works in much the same way as the client-side VBScript example that we saw a moment ago. Here's the JavaScript:

 

d = new Date();

document.write(d);

This all looks rather frightening, doesn't it? The first line in this short two-line program basically creates the built-in JavaScript object, Date, which is found on the client-side, in the browser, and generates the current date. The program reads this date into something known as a variable (we're not going to explain variables here, but they are covered in detail in Chapter 4) . The second line displays the contents of the variable.

Choosing Between VBScript and JavaScript

JavaScript can be more difficult than VBScript for the novice programmer to master – and it's often even more confusing to try to learn two languages at once! This, in itself, is a good enough reason for selecting VBScript as the language of choice for the remainder of this book. Of course, this book is oriented towards server-side scripting with ASP – and, conveniently, VBScript is the default scripting language on the IIS web server.

 

On the client side, the more widely-supported scripting language is JavaScript. It's worth noting that client-side script can help to ease your web server's load. We'll see an example of this in the Wrox Classifieds ASP application that we'll build in Chapter%2015 – which employs a couple of useful little client-side scripts to perform data-checking functions on the browser, and hence reduce the number of times the browser needs to communicate with the web server.

 

So ultimately, you may wish to learn about JavaScript too. However, VBScript is a great way to get into scripting, and so it is the language that we'll be learning throughout the course of this book.

 

If you do want to know more about JavaScript, you may be interested in Beginning JavaScript 3rd Edition (Wrox, ISBN 0-470-05151-5).

<< 2.2.3- Server-Side Scripting

Chapter2

2.3.0- The Order of Execution >>