Scripts in Web Applications

See Also      Tasks

To display text, images, or links in a page, you add text and format it with HTML tags. However, to control the way a page behaves, you create script, or programs that you embed in a Web page to perform specific functions, such as:

• Controlling what happens when a user clicks a button, enters text, or submits a form.
  
  
• Navigating to a specific page based on a condition such as user preference.
  
  
• Collecting and storing user information in order to customize Web applications dynamically.
  
  
• Querying a database and displaying results.

You can create script in different ways:

• Use design-time controls, which allows you to set property values and enter values in dialog boxes, and then generates script for you.
  
  
• Write your script in Source view of the HTML editor.

Microsoft^® Visual InterDev™ supports a complete scripting object model that allows you to use standard object-oriented techniques for creating Web pages. For details, see The Scripting Object Model.

How Scripting Works

The script's source code appears in the page, as shown in this example.

Script source code

When the page is requested, the script is read along with all the other text on the page. The server or browser reads the scripts and checks for errors, and then runs the script.

Because scripts are simply blocks of text, you can write a script in one page, and then include it in multiple additional pages. For details, see Writing Reusable Script.

Scripting Languages

You can write scripts in any scripting language that you are comfortable with. Common scripting languages include Microsoft^® Visual Basic^®, Scripting Edition (VBScript) and ECMAScript, a standard scripting language. Popular implementations of ECMAScript are Microsoft JScript™ and JavaScript.

Because scripting languages are interpreted, you must be sure that when the user requests a page, the user's browser (and server, if you are writing server script) can use the language in which you have scripted. For example, if you write all your scripts in VBScript, you must be sure that the user's browser can interpret VBScript. Microsoft Internet Explorer supports VBScript, but not all browsers do. For details on determining the capabilities of a browser, refer to the documentation for your browser, and see Creating Portable Script.

You can use different scripting languages on the same page if necessary. This might be the case, for example, if you are adding your own scripts to scripts generated by a design-time control. When you use design-time controls, you specify a target scripting platform (client or server), which determines by default what language to script in. For details, see Creating Forms with Design-Time Controls.

If you are scripting outside of design-time controls, you often work in only one language, so you can specify a default language for each new page that you create, and if you need to, for individual scripts. For details, see Choosing a Scripting Language.

Client and Server Scripts

If your server is Microsoft^® Internet Information Server (IIS), you can create .asp files that contain both client and server scripts. Both types of scripts can appear in the same page.

Client scripts are part of a page, and are sent to and run by the browser when a user requests the page.

Server scripts are also part of a page, but are not sent to the browser. Instead, they are run by IIS after the page is requested but before it is passed to the browser. When the page is sent to the browser, the server has already run the server script and removed it from the page.

Client and server script execution

The ability to specify that a script runs on the client or on the server is an important feature of Web scripting, which allows you to specify the right run-time environment for the task you want to perform. For example, the following are tasks typically performed using client scripts:

• Change the text or appearance of a page at the time it is loaded in the browser or in response to an event such as a button click.
  
  
• Perform validation on data entered into an HTML form before it is sent to the server, such as making sure that an employee ID number contains the correct number of digits. In contrast, verifying data against a database is typically a server-side task.
  
  
• Display information in response to a user event such as a button click.

In contrast, these are tasks that you would typically perform using server scripts:

• Query a database and feed the results to an HTML page. For details, see Viewing Data.
  
  
• Redirect a user's request to a specific page based on a condition, such as password lookup. For in-depth information about using scripts to move between pages, see Extending the Scripting Object Model Across Pages and Navigating Conditionally.
  
  
• Process the information entered by a user on an HTML form. For in-depth information about how to create scripts for processing HTML forms, see Writing Script for Script Objects and Gathering Information Using Forms.

Although the tasks listed above are typical uses for client or server scripts, they are not rigid rules. For example, you can use Visual InterDev design-time controls to create server script that responds to a client event such as a button click. As another example, if your users use Microsoft^® Internet Explorer 4.0 or another browser that supports Dynamic HTML (DHTML), you can write an application that accesses a database from the client browser.

The decision to use client or server script therefore depends not just on the task you are accomplishing, but the environment in which your application runs, specific constraints (such as performance), and so on.

Client Script Processing

Client scripts are processed by a browser such as Microsoft^® Internet Explorer, which calls the appropriate run-time module to execute the script. Client scripts are enclosed between <SCRIPT> and </SCRIPT> tags. The following simple example shows a script that prints the current time on the page:

<SCRIPT LANGUAGE="VBScript">
   Document.Write time
</SCRIPT>

Your page can contain as many script blocks as you need. You can put multiple functions and subroutines into a single script block, or put each in a separate script block.

If your Web application might run on a browser that cannot process client scripts, you can embed the script within HTML comment tags so that nonscript-capable browsers ignore it. The following client script shows a script block in comments:

<SCRIPT LANGUAGE="VBScript">
<!--
   Document.Write time
-->
</SCRIPT>

Client scripts are processed at different times, depending on how they are written:

• Statements can appear in a script block but not as part of a procedure (function or subroutine). These are called global or inline scripts, and are processed in order when the browser reads the page. For example, the following shows a global script:

  <SCRIPT LANGUAGE="VBScript">
  <!--
  Document.Write time
  -->
  </SCRIPT>
  

• Statements can appear as part of a procedure, such as a function or subroutine. These are not executed immediately. Instead, they are parsed when the page is run and checked for syntax errors. However, they are not run until the procedure is called.
  
  
• Event-handling procedures are not executed immediately. Instead, they are executed when the user performs the event that triggers the script, such as clicking a button. For example, the following script illustrates an event-handling subroutine that is executed only when the user clicks the Submit button on a form:

  <SCRIPT LANGUAGE="VBScript">
  <!--
  Function btnTest_onclick
     If Len(Document.frmTest.txtName.value) < 1 then
        Alert("You must enter a name!")
     End If
  End Function
  -->
  </SCRIPT>
  

Scripts for event-handling procedures, subroutines, or functions can appear anywhere in a page, because they will be processed only when needed. However, it is common to put these types of scripts in the header of a page.

When you write client scripts, you can access objects on the page to get their properties or write event handlers for them. The exact list of objects available for you to work with depends on the type of browser that your users will be using. For more information, see Document Elements and Scripting with Design-Time Controls and Script Objects.

Client scripts can directly interact with the user by posting message boxes for output and by using dialog boxes or forms for input. For example, if a user makes an error when entering information in a form, a client script can display an error message (as shown in the preceding example).

For more information about displaying information, see Displaying Information to the User. For information about using forms from both client and server scripts, see Scripting with Design-Time Controls and Script Objects and Gathering Information Using Forms.

Server Script Processing

In Visual InterDev, you put server script in Active Server Pages (.asp files). The .asp extension on the file alerts IIS that the page can contain server script. When IIS reads the page, it looks for server script and processes it. After the server script in an .asp file has been processed, it is removed from the file, which is then sent to the browser (including any client script that might be in the file). The browser treats the .asp file as it does an ordinary .htm file.

Server script can modify any aspect of a page before sending it to the browser. Typically this involves performing tasks and incorporating the output of the tasks into the HTML text of the page. However, server script can just as easily create client script, because client script is nothing more than additional text on the page.

A special case of .asp file processing is the Global.asa file. This file contains scripts that respond to application-wide events: each time the ASP application is started or closed, and each time a new user starts a session.

You can create server script in the Global.asa file for these events, which is useful for tasks such as storing application settings (for example, the default scripting language); initializing application-wide variables; maintaining counters; and so on. For details about creating event handlers in the Global.asa file to store global information, see Sharing Dynamic Information.

When you write server script in an .asp file, you distinguish it from other text (including client script) in one of two ways:

• Within the delimiters <% and %>. Any text between these two tags is processed as inline server script by IIS. The <% %> delimiters are often used to enclose expressions that are evaluated and inserted into the HTML text of a page. For example, the following server script displays the current time on a page:

  <% response.write time %>
  

• In a <SCRIPT> tag (as with client scripts), but with the RUNAT=SERVER property, which is used to enclose stand-alone procedures such as functions and subroutines. The following example shows the RUNAT property:

  <SCRIPT RUNAT=SERVER>
     Function GetDate
        [some script lines here]
     End Function
  </SCRIPT>
  

In the Visual InterDev HTML editor, server script appears in yellow to distinguish it from client script. The following illustration shows a page that includes both server script (bracketed in yellow) and HTML text.

Editing server script

Server script is generally not event-driven. Exceptions are the event handlers in the Global.asa file and server event handlers created by design-time controls. Instead, when the ASP page is requested, the server reads the page and processes all server script from top to bottom. The script performs whatever calculations and database access you write, and evaluates all expressions and variables. Stand-alone procedures are called as needed.

Because the script is running on the server, it has access to the objects available on the server. For example, a server script running on IIS can reference the ASP Application, Session, Request, and Response objects. A server script could not, however, make use of the objects available in the browser — for example, a server script could not use the Internet Explorer Document or Window objects.

When you write server script, you must be careful to use only objects that are available in the context of the server. For more information about objects that you can use in server scripts, see Document Elements and Scripting with Design-Time Controls and Script Objects.

If the server script produces some output — for example, if you want to display the value of a variable, or display some records retrieved from a database — you can place the output on the page using the Response.Write method (or using the abbreviated form, the "=" operator) in inline script. For example, the following simple page shows server script that calculates the current time and puts it into a variable. Later in the page, the value of the server script variables are integrated into some HTML text:

<%
vDate = date
vTime = time
%>

<HTML>
<BODY>
When the script ran, it was <%Response.Write vTime%> o'clock on <%=vDate%>.
</BODY>
</HTML>

When the page is processed, the server evaluates the expression following Response.Write or "=", and its value is placed at that point in the HTML page stream. When the page is displayed in the browser, it will look something like this:

When the script ran, it was 10:46:30 o'clock on 12/31/97.

If you look at the source of the page, it would look the same as the page output. You would not see the expressions <%Response.Write vTime%> or <%=vDate%> in the source, because those expressions would have been evaluated by the server before the page was sent to the browser.

Server scripts can produce any type of output, including not just values for variables or expressions, but HTML tags and text and even client scripts.

For more details about how to create server scripts, see Introducing Active Server Pages.