See "Application and Session Objects" for more information about Active Server Pages components, in Chapter 10.
A brief look at the history of the BASIC language, and Microsoft's role in its development..
We take a brief look at the Visual Basic Family of Tools.
This is our first look at how scripting looks within an HTML file, and how the two integrate to create dynamic content.
Scripts can be executed at the client, on the server, or on both ends of the connection.
VBScript, while the default scripting language of Active Server, is not the only option for ASP script development.
A Brief History of Microsoft's BASIC Languages
The history of the BASIC language is a good place to start when putting VBScript and Active Server Pages development into perspective. The Beginners All Purpose Symbolic Instruction Code, more commonly known as BASIC, was developed in 1964 at Dartmouth College by Kenney and Kurtz. It was initially designed to provide students with an easy to understand procedural language, which would be a stepping stone to more powerful languages like FORTRAN. In the intervening 30+ years, a great deal has happened to this introductory computer language.
The language has grown and become more feature-rich over the years due mainly to its vast acceptance in the marketplace. To understand the evolution of the BASIC language and how it has become the default language of Active Server Pages scripting, we begin our story in 1975 when a young man named Bill Gates, was attending Harvard. Attracted by an article about the forthcoming M.I.T.S. Altair computer, Paul Allen and Bill Gates developed a version of BASIC that would run on the Altair and was eventually licensed to M.I.T.S. for their Altair computer. When version 2.0 was released later that same year, it was available in two versions, a 4K and an 8K. Imagine the entire development system implemented in 4096 bytes! Today, you would be hard-pressed to find a Microsoft Word template that is that small. Basic was the first product ever sold by Microsoft. Two years later, after porting their version of BASIC to other platforms (CP/M, for example) the exclusive license with M.I.T.S. for Microsoft Basic ended. In 1979, Microsoft released MS-Basic for the 8086, a 16-bit product.
Bill Gates won the opportunity to provide the operating system for the new IBM personal computer after IBM's courting of Digital Research Inc. to license their CP/M operating system failed. Microsoft licensed the SCP-DOS operating system and modified it to run on the IBM-PC. The MS-DOS operating system version 1.0, bundled with MS-BASIC was the engine driving the beginning of the personal computer revolution.
Over the years, Microsoft saw how attractive BASIC was and created a compiler for the language in the form of QuickBasic. QuickBasic reigned supreme until version 4.5, when it was replaced with PDS Basic (Professional Development System).
We had no idea in that spring of 1991 that many of our lives were going to change so dramatically. Visual Basic was announced at the Windows World '91 conference on May 20, 1991. The Visual Basic environment was to provide graphical application development and an integrated debugger and to create compiled executable windows programs, all using the BASIC language. Many Windows developers still remember the first time that they used Visual Basic version 1.0. After thrashing their way though learning the ins and outs of the C language and building Windows applications with Microsoft C and the SDK, they couldn't believe the power inherent in this innocuous little visual development package.
Visual Basic for Windows was followed by Visual Basic for DOS. When the DOS version came out, there were (and still are) many programmers with DOS machines in our companies. The DOS version of VB addressed the RAD methodology on the DOS platform. Even though the product never made it past version 1.0, it was a useful tool for creating graphical applications for the DOS environment.
By the time Visual Basic version 4.0 was released in 1995, countless numbers of programmers were hooked on the Visual Basic development environment. It's easy learning curve, intuitive interface, and bundled components, combined with incredible extensibility and its tightly integrated environment make it the logical choice for millions of developers each day.
The Visual Basic Family Tree
As you learned in the preceding section, getting from the M.I.T.S to Visual Basic for Windows took some time. In the last few years, the Visual Basic family has been very fruitful (and has multiplied). In the next several sections, you will take a look at the various incarnations of the Visual Basic language as it is available today and develop a greater appreciation for the differences and similarities in the VB family. The family portrait is found in Figure 6.1. More specifically, for all of you Visual Basic programmers out there (VB or VBA), we will take a good look at what VBScript leaves in, and more importantly, leaves out.
Each member of the VB family has an important role to play.
Visual Basic
The Visual Basic programming tool is a professional development environment suitable for developing multi-tier, enterprise level, client/server applications. It's inherent extensibility in the form of supporting OLE and ActiveX controls and its capability to integrate WIN32 API calls, as well as third-party DLL's provide a rich environment for creating applications.
Visual Basic is used by millions of programmers all over the world. It is used mainly for personal and corporate application development, but in the past few years, commercial applications that were developed in VB have been showing up in the market place.
The current version of VB is 4.0 and is available in three packages: standard, professional, and enterprise. The standard package is ideal for the computer hobbyist or student. It provides all of the base functionality without including (in the price or the package) a number of custom controls that are appropriate for larger scale development. Moving up to the Professional addition provides additional custom controls, the capability to interact directly with databases (not requiring data bound controls), and the capability to create remote automation servers. The professional and enterprise offerings differ only in their capability to provide remote data objects. The professional version is suitable for many corporate application development needs, while the enterprise edition also integrates Microsoft's Visual Source Safe, a source code management and team development tool.
In December, Microsoft made the Visual Basic Control Creation Edition available for download from their Web site http://www.microsoft.com. VB CCE is a new version of Visual Basic that provides a first look at some of the features that will show up in Visual Basic 5.0. The remarkable thing about VB CCE is that it can create ActiveX controls, which you can integrate into your Web applications on the client and server-side.
As the Visual Basic product continues to mature, it will remain the tool of choice for millions of developers to create robust, scaleable, multi-tier applications. With the introduction of Microsoft's Active Server framework and their middleware transaction processing product, code named Viper, Visual Basic will come to the forefront as the tool for creating the client side of the next generation of corporate and commercial applications.
Visual Basic for Applications
Visual Basic for Applications, or VBA as it is more commonly known, is a powerful subset of the Visual Basic environment. Microsoft released, at the end 1996, VBA version 5.0. The company has integrated VBA across the entire Office 97 applications suite. They have also made it available to third-party developers for inclusion within their applications. At this year's Fall Comdex computer show, over 40 companies were showing their products with an integrated VBA programming engine. As of the printing of November's second week ComputerWorld, an additional 60 third-parties had signed up to integrate VBA into their products.
VBA is a shared development environment within the hosting application, including an integrated code editor and support for debugging. With its support for OLE automation, it is often used as an integrating tool to create custom applications from within Word, Excel, or Access. Any application that exposes its objects as OLE or ActiveX controls can be used by VBA developers. Many of the familiar tools from the Visual Basic IDE also have made it into VBA 5.0. Features such as the code window, project explorer, properties window, and the object browser make the VBA environment very similar to its bigger sibling.
In the Office 97 products, as well as other products that host VBA 5.0, users will have access to Microsoft Forms, creating a development environment with the same forms metaphor as Visual Basic. Because all VBA 5.0 applications share the same forms environment, any form object created in one application can be used by any other application. This tight integration and code reusability makes VBA the language of choice for imbedded programming engines.
The wonderful thing about VBA is that you can learn the language from within one application or environment, and it is immediately transferable to (what will soon be) hundreds of other products. In addition, you can easily scale up to the complete Visual Basic environment or move down to create powerful Inter/intranet applications with VBScript and Active Server Pages. For anyone wanting to choose the best environment for learning to develop with VB within an application environment, VBA is an excellent choice.
Visual Basic Scripting Edition
The scripting edition of Visual Basic is a smaller subset of the Visual Basic for Applications language. It is intended for use in Inter/intranet application development and is currently supported in Microsoft Internet Explorer version 3.0 and above. It brings much of the power and flexibility of the Visual Basic language to the Internet and intranet. On the client side, there is the opportunity to interact with ActiveX controls to provide active and interesting content. On the server-side, the scripting language is used and integrated within HTML to provide a new level of functionality and ease of use in Web site development.
For VB or VBA programmers, the transition to Active Server Pages development using VBScript from a traditional client/server environment will be less a challenge of learning the idiosyncrasies of a sister language than a challenge of changing to the new net development paradigm. Programming in any language consists of expressions, statements, and procedures. The trick is to figure out how the language integrates with the environment in which it will be implemented. In the case of VB or VBA, the environment is the Windows operating system.
VBScript, on the other hand, will be implemented on the client, using ActiveX controls, as well as on the server in ASP, integrating a variety of components to create dynamic pages. You will be dealing with, not only the scripting language, but also its integration into HTML code. At first, having your code in pieces throughout the HTML page will take some getting used to. But, just as it was a struggle to master the VB IDE, you will master VBScript and Active Server Pages development.
If you are coming to Active Server Pages development from a strictly HTML background, you also will have a learning curve to climb. If you have been developing Perl or REXX scripts, the language features of VBScript will not be that foreign to you. Also, you have been used to adding additional tags as the HTML standard emerges. You can treat VBScript and the associated implementation as just some additional tags to integrate. But, be sure to utilize the new components that ship with Active Server
Pages. This powerful set of ASP components include such features as session and application management, and database connectivity. It would be very easy to use VBScript for some minor chores and revert back to the old CGI way of doing things for database access and other local processing tasks. Learning to use the VBScript language and its associated ASP components will be worth it. You don't have to rely on my word; just check out the hundreds of Active Server Pages sites that are already in production (including at Microsoft) even though as of this writing, the product is still in Beta!
See "Application and Session Objects" for more information about Active Server Pages components, in Chapter 10.
Feature Set and Limitations in VBScript
I know that you are really looking forward now to a huge table filled with each and every difference between the lovable VB language syntax and VBScript. Well, we must apologize; we just couldn't bring ourselves to create that beast. What you are going to find in the next few pages is a list of some of the most important, or widely used functions that your typical Visual Basic developer might immediately miss. This is not going to be an exhaustive coverage. Just the facts Ma'am. If you must have the complete list, line by line, of the differences between VBA and VBScript, please refer to the VBScript documentation that ships with Active Server Pages.
Array Handling
Arrays are useful in hundreds of situations, and when you can have an array of objects, that number jumps again. Many times it is useful to change the base of an array variable for a specific implementation. For example, if we were to create an array representing the days in February, it would make sense to start the array at 1 and go to 28. This is not possible in VBScript. All arrays must have a lower bound of zero. The same is true of multi-dimensional arrays: all lower bounds begin at zero. This doesn't affect the performance at all; you just need to remember to get to element n, always subtract 1. So, in VBScript, your February array index would go from 0 to 27.
Collections and Classes
These are two of the most cherished features in the most recent release of Visual Basic. The addition of classes to the Visual Basic language enables us to get that much closer to fully supporting object-oriented development. You will not be able to create a user-defined collection within VBScript. You also will be unable to create a class. If you do want to add functionality within a class, create the class in Visual Basic and then create an OLE component. You can then create an instance of the class from within an Active Server Pages script using the CreateObject syntax. There are a number of collections that you will find within the Active Server Pages environment, and you will treat them as you would in Visual Basic: walking the collection, setting items, and so on; you just can't create your own.
Conversion
There are a number of conversion functions that are supported in VBScript. The most glaring omission is the Format command. This is the one command that will surely be missed the most. We understand that this is on the list for inclusion in the next release of VBScript.
Data Types
No intrinsic data types are found in VBScript. The only data type available is the Variant, which makes complete sense considering that VBScript is an OLE-implemented language. All passing of values between OLE objects is performed through Variant variables.
See "Creating Your Server Component" for more information about creating your own components for use within VBScript, in Chapter 14.
See "VBScript Data Types" for more information about data types and variants, in Chapter 7.
Dynamic Data Exchange
This venerable method of inter-process communication was the forerunner of OLE. I remember using DDE last year to interface with a software program controlling a PLC (programmable logic controller) to create a hydraulic pump testing system. Given the built-in support of OLE objects, DDE is not supported in any form in VBScript. This is a feature that could potentially, if included, violate the integrity of the client machine. Imagine a script that runs during startup and via DDE looks for the windows explorer, finds it, and then sends messages telling it to format your hard drive!
Dynamic Link Library Support
One of the features of Visual Basic that makes the product so extensible is the capability to declare and call functions within Dynamic Link Libraries (DLL). This feature provides you with the method to call any of the Win32 API functions and a host of other functions available in third party DLL's. Although many of the functions in DLL's are now available as OCX/ActiveX controls, there are many that you might have created over the years that you still wish to use. You have a few options: First, port the DLL to an ActiveX object. Next, if you don't have the source or are not wanting to change the DLL, you can wrap the DLL's functions within a VB class and then create an OLE Server for use in your ASP scripts.
Debugging Support
One of the nicest things about VB is its integrated development environment (IDE). You could debug your application line by line, changing variable values on-the-fly. There is no IDE for VBScript and Active Server Pages development (yet) and no support for the Debug.Print, End or Stop commands. Once again, you can build a simple component to provide the Debug.Print functionality very easily. On the client side, Microsoft just released in December the "Microsoft Script Debugger for Internet Explorer," which enables interactive debugging of scripts executing within Internet Explorer client. This free download is available from Microsoft at http://www.microsoft.com/workshop/prog/scriptie.
Error Handling
There is error handling available when developing ASP applications. The familiar On Error Resume Next command is still available, although branching on errors is not. You also have access to the Err object to retrieve error numbers and descriptions. When an error occurs in your .asp scripts, error messages are sent back as HTML to the client, and depending on their severity, can also be written to the IIS log and the NT Server log.
File Input/Output
All of the language features that enable access to local files (File I/O) on the system in which an application is running have been removed from VBScript to enhance the security of the language on the Inter/intranet. This prevents an errant VBScript program executing on a browser from damaging data on the client machine.
User-Defined Types
The last, and my favorite, feature of VB that is not included within VBScript is the capability to create user-defined types. There is no better construct for dealing with database and transaction-oriented data than the user-defined type. It will be sorely missed.
The Last Word
There are a number of features that are not yet or never will be available in VBScript. As the language is deployed and continues to mature, those features that are most requested and do not violate the security constraints will be added to the language. There are two main reasons why VBScript must be a smaller subset of VBA-security and size.
The VBScript code will be executing on the client and the server systems. If the VBScript code had access to the native file system on the computer that it was running, it could potentially wreak havoc with the data contained within. Imagine pulling up a new page and having your hard drive mysteriously formatted, or having key files destroyed. Just as we safeguard our computers with virus protection programs, Microsoft has safeguarded your browser by limiting the functionality of the VBScript language.
The second reason VBScript must be a subset is the "weight" of the language. This is a language designed for use over the Internet and intranet. If you end up shipping the OLE scripting engine over the net to fulfill a request, you want to ensure that the language is relatively small to minimize the transfer time.
Regardless of the real or perceived shortcomings within the VBScript language, there is nothing better or more powerful for creating and implementing dynamic content over the net, using Active Server Pages.
When executing code on the server, security is not as big an issue. Assume for the moment that any component you build will not damage the machine. With that said, any functionality that is missing in the VBScript language that you require can be easily added by creating an OLE component. Because VBScript can create an instance of any OLE or ActiveX component, it is easy to provide the native VB functionality to your server-side VBScript Active Server Pages.
See "Constructing your own Server Components" for more information about creating your own components, in Chapter 14.
Scripting and HTML
A script is composed of a series of commands that will be executed by the host environment, meaning that scripts will be executed on the client or on the server. Active Server Pages contain scripts that execute within the client browser as well as the server. Within a script, you can perform a variety of activities such as:
The scripts within an ASP page are passed to a scripting engine within the client or server environment. A scripting engine is a Component Object Model (COM) object that is called to process the script. Within the scripting engine, the script is parsed, checked for syntax, and then interpreted. The resulting actions, deciphered by the interpreter, are then performed within the host environment. Because the scripting engine in the Active Server Pages environment is a COM object, you can add additional scripting engines to support multiple scripting languages. Support for VBScript and Java Script are bundled with Active Server Pages.
Script Delimiters
Within an HTML file, we use delimiters around tags to tell the client that we are requesting an HTML tag, not just text to be displayed. We also need delimiters to let the host environment know that there is scripting within the page. The scripting delimiters that wrap around our scripting are <% and %>. Text within the script delimiters will be processed within the host environment before the page is executed. Here are a few examples of how the script with delimiters looks within your ASP page:
<HTML> <HEAD> <TITLE>Scripting in HTML</TITLE> </HEAD> <BODY> <P>We will now create a variable, assign a value to it and then <BR> display the value of the variable within our page</P> <% strName ="steve" %> <P>We have created a script variable called strName and have<BR> assigned a value to it. The value is <%=strName%> </P> </BODY> </HTML>
Notice that we can intersperse scripting commands almost anywhere in our .asp file. The script expression is evaluated, and the resulting value is inserted into the HTML file sent to the client. Within the first set of scripting delimiters, you create a variable strName and assign the value of steve to it, using the equal sign to perform the assignment. When we want to display the value of the variable on the client, we again use the equal sign to place the value into the HTML file =strName.
Scripting Statements
When you create variables or put single values in-line in an .asp file, it is referred to as a single expression. Single expressions are bits and pieces of code that resolve to a value. Statements, on the other hand, are complete logical units that perform one type of action. An example of a statement can be shown using the If statement:
<% If Time > #8:00:00AM# and Time < #5:00:00PM# Then strMessage= "Get Back to Work!" Else strMessage = "You should be at home, resting." End If %> <P> Sir or Madam, <%=strMessage%> </P>
Imagine the poor unsuspecting office worker who happens to pull up this page during the day from the corporate intranet. If the time is between 8:00 am and 5:00 pm, he will get a Dilbert-style management command. Any other time, he will be reminded that there are much better places to be than at work. Now, I know that many of us are not fortunate enough to have a standard 8 to 5 job (and who really wants one anyway?), but it remains a good example of a scripting statement within HTML code.
See "Variables 101: The Basics" for more information about Variables, in Chapter 7.
See "Conditional Processing" for more information about statements and program flow, in Chapter 8.
Scripting Blocks
Just as you enclose tables and forms in beginning and ending tags, you encode script blocks in beginning and ending tags as well. Using the <SCRIPT> and </SCRIPT> tags notifies the host environment to expect a block of scripting code within the tags. By using these tags, you can create procedures that can be called from anywhere within the page. A procedure is just a number of scripting commands that are grouped together to perform a specific function. If you try to define a procedure within script delimiters alone, you will generate syntax errors.
Now, combine the last two topics just discussed, scripting languages and procedures, and take a look at some scripting code in action. You are going to create two simple procedures, one in VBScript and one in Java Script that will be invoked within the same page. For now, don't worry too much about the scripting syntax; just try to get a feel for how the scripting is integrated into the ASP page. First, create the VBScript procedure:
<SCRIPT LANGAUGE=VBScript RUNAT=Server>
Sub vbwrite
response.write("Hello from VBScript")
End Sub
</SCRIPT>
Now here is the Java Script procedure that will be invoked next:
<SCRIPT LANGAUGE=JavaScript RUNAT=Server>
Sub jwrite
response.write("Hello from JavaScript")
End Sub
</SCRIPT>
Putting it all together with a little HTML results in:
<HTML><HEAD><TITLE>Mixing Scripts</TITLE></HEAD><BODY> <P>First we have output from VBScript</P> <% Call vbwrite %> <P>Now from JScript</P> <% Call jwrite %> </BODY></HTML>
The VBScript and Java Script scripting languages are functionally equivalent and share much of the same syntax. If you start using other scripting languages like Perl or REXX, you will find that they are quite different in syntax than VBScript or Java Script, but retain the same programming constructs. But, if you are a crack Perl or REXX developer and want to make the transition to Active Server Pages development without learning a new language, you are in luck. Because the scripting engine is a COM object, which is called to process a file under ASP, you can integrate a Perl or REXX script processor into Active Server Pages.
Notice in the preceding example that we used an additional attribute of the <SCRIPT> tag, RUNAT. This attribute determines where the script is executed, and it is a nice transition into the next topics, the primary scripting language and client-side and server-side scripting.
Procedures are an ideal way to create logical units of functionality that can be called from within your Active Server Pages script. To reach the next level of functionality and to provide a medium for code reuse, ASP provides the capability to include code from another source file into an ASP script. This capability is called Server-Side Includes, and is a syntax used to insert the contents of one file into another.
This include capability is a familiar one to C and C++ developers who have been including header files since the day they began application development. Still, this simple feature adds an additional level of functionality to Active Server Pages. For example, if we had a great procedure in a file called grtproc.htm and wanted to add the procedure to our new file, we would use the Server-Side Include syntax as follows:
<!--#INCLUDE FILE="grtproc.htm"-->
Now you could call the great procedure in grtproc.htm in your new .asp file.
See "Using Server-Side Includes" for more information about Server-Side Includes, Chapter 9.
Changing the Primary Scripting Language
Embedding scripting within your ASP pages, using only the scripting delimiters, is referred to as primary scripting. The code in primary scripting is executed against the default scripting engine for the page. In Active Server Pages development, the default scripting engine is VBScript. You can select a different scripting language for a page or block of script within a page by setting the <SCRIPT> tag as follows:
<SCRIPT LANGUAGE=JavaScript>
This code line will notify the host that the script within the page uses Java Script syntax.
You can also mix multiple scripting languages within a page by changing the scripting language tags within the page itself:
<SCRIPT LANGUAGE=JavaScript> …Java Script Code Here </SCRIPT> <SCRIPT LANGAUGE=VBScript> …VBScript Code Here </SCRIPT>
Client-Side Scripting
Client-side scripting refers to the scripts that are interpreted and executed in the client browser. When you are scripting for the client, you have access to the object model available within the browser. You will also create scripts to interact with user interface objects on the client.
There are a number of tools available to create client-side pages and their associated scripting. The ActiveX Control Pad is a good example of such tools. This Microsoft developed, freely available product enables you to design Web pages, adding ActiveX controls and standard HTML fields at design time. The program then generates the HTML code to create the page. After the page has been created, you can edit the file and add scripting to provide such client-side features as field validation, custom responses to user actions, and a host of other capabilities inherent in the client's browser. The ActiveX Control Pad can be found at http://www.microsoft.com.
As mentioned previously, the opportunity for field validation of data at the client is an important feature of client-side scripting. You can have the page validate the data before it is sent to the server. This ensures that you will not receive a message immediately back from the server requesting you to provide complete, or correct, information. In addition to providing validation errors more quickly to the user, this also can reduce network traffic. In the following
example, you create a simple page that contains a field that you will validate.
<HTML> <HEAD> <TITLE>Scripting in HTML</TITLE> </HEAD> <BODY> Enter a Value <INPUT TYPE=INPUT NAME=TxtField SIZE=20> <INPUT TYPE=BUTTON VALUE="Submit" NAME="BtnSubmit">
You have now created an input field of name TxtField and have created a button to submit the page. You now create an event that executes when the BtnSubmit button is clicked.
<SCRIPT LANGUAGE=VBScript>
<!--
Option Explicit
Dim bValid
Sub BtnSubmit_OnClick
bValid = True
Call CheckField(TxtField.Value, "Please enter a value in the field.")
If bValid Then
MsgBox "Thank you for filling in the field"
End If
End Sub
Although the default language of Active Server Pages is VBScript, in the Internet Explorer (IE), it is not. If you do not explicitly state LANGUAGE=VBScript, the default language in IE, JavaScript generates errors within your pages.
The first line is the script tag that you learned about in the section "Scripting Blocks."
This script tag lets Internet Explorer know that we are preparing to provide scripting instructions using the VBScript language. The next notable section is the procedure created to respond to the click on the BtnSubmit button. Notice the syntax OnClick makes perfect sense, and should be very familiar to you if you have any VB development experience, where the procedure would be named BtnSubmit_Click. This is the procedure that we want to execute when the button is clicked. The script then checks the field to see if it has a value in it. If so, the field information will be sent to the server. If not, the user sees a message to input an appropriate field value.
Sub CheckField(ByVal strFieldValue, ByVal strMessage)
If strFieldValue = "" Then
MsgBox strMessage, 0
bValid = False
End If
End Sub
-->
</Script>
</BODY>
</HTML>
This last bit of code is the procedure that implements the field validation. Notice that we are only checking for any text entered in the field. We could have written a more involved procedure that could check for a range of values or convert the values to all upper- or lowercase. For now, don't worry too much about the syntax of VBScript (the rest of this section is devoted to that). You should just, again, begin to get a feel for how the client scripting is integrated into the HTML code.
When you create a page with scripting and define procedures within script tags, the default RUNAT (where the script will execute) is the client. So, any scripting that you include within the scripting tags without specifying the RUNAT attribute will execute on the client.
Server-Side Scripting
Now we get to the meat and potatoes of our scripting discussion. Server-side scripting occurs when the scripts within the page are executed at the server, before the page is ever sent to the client browser, as shown in Figure 6.2. This is an incredibly important distinction. It means that the server is responsible for generating the HTML that is ultimately sent to the client. You do not have to worry about the client connecting to a database, reading from a file, querying an on-line service, or any of the thousands of other actions that take place on the server to fulfill the client request.
Active Server Pages provides server-side scripting for the Internet Information Server Web server. In addition to enabling custom scripting to be developed, you can also integrate almost any ActiveX component (that doesn't require a user interface, of course) into your server scripts. This opens the door wide and enables a level of functionality that was difficult, if not impossible, to achieve with traditional methods of server-side processing.
Active Server Pages scripts execute on the server before passing the page to the client.
Server-side scripting blocks are executed at the server when the ASP interpreter finds the scripting tag with the RUNAT attribute set to SERVER. In code, it looks like this:
<LANGUAGE=VBScript RUNAT=SERVER>
When an Active Server Pages page is requested, the server will call ASP. The .asp file is read through from top to bottom. Any scripting that needs to execute on the server is performed, and then the dynamically created HTML page is sent back to the client.
Notice that the code in the CheckField subroutine creates a message box to respond to user input. If you were to mistakenly add the RUNAT=SERVER to the client code, the message box would never be shown on the client because at the server, there is no interface to show a message box upon. But, what you could do at the server is generate custom messages based upon the time of day, or based upon data in a database and pop those messages in the client browser when the validation takes place. You can do this by dynamically generating client-side scripts from the server.
Modifying Client Scripts from the Server
When we create Active Server Pages applications, we are normally interested in creating dynamic content for our clients to view. We do this by interacting with ActiveX components and databases and even legacy systems to provide dynamic, up-to-date information.
One of the more exciting aspects of this capability to create dynamic HTML content is the capability to create client-side scripting on-the-fly. In essence, we are dynamically creating scripting, based on server information and embedding it in the HTML page that we return to the client. These dynamically created scripts will then be executed on the client's browser.
The more you think about this capability, the more situations you will think of to use this powerful new functionality. You can create custom on_load events that are invoked when the page is loaded on to the client. You can also dynamically create scripts that respond to user events on the client.
Currently, there are a lot of pages out there full of VBScript and Java Script. The problem with them is that once they are created and posted to the net, you cannot do anything to change them without editing the source file. Now, using Active Server
Pages, you can prepare scripting variables on the server-side to be used by the client. For example, say that you want to create a VBScript array for use on the client with real-time information stored in a legacy system. Today, that would be problematic at best. Using server-side scripting, you can query the legacy system using a database access component and then populate the array before returning the page to the client. In another scenario, you could have custom client-side validation scripts generated by the server, based upon external values stored in a database.
When an Active Server Pages script is run, ASP processes any commands within a comment block with the scripting tags <% and %>, regardless of where the are within the script. In the following code, the server-side script will be executed within ASP, even though the script resides in a scripting block which has no RUNAT=SERVER parameter.
<SCRIPT LANGUAGE=VBScript> <!-- <% server side scripting commands %> --> </SCRIPT>
In the following example, the server script will create three VBScript subroutines which will subsequently execute on the client machine.
<HTML><HEAD><TITLE>Client Side Scripting From The Server</TITLE></HEAD>
<BODY>
<%
tmeServerTime = Now
For i = 1 to 3
%>
<SCRIPT LANGUAGE=VBScript>
<!--
Sub Server_Time_<%=i%>()
MsgBox "The time at the server is <%=tmeServerTime%>" _
& " on pass <%=i%>"
End Sub
Server_Time_<%=i%>()
-->
</SCRIPT>
<%="Server side loop " & i & "<BR>"%>
<%
Next
%>
</BODY>
</HTML>
When you execute this code in your browser and look at the source, you will see three VBScript procedures named Server_Time_1, Server_Time_2 and Server_Time_3. Each of these procedures was generated dynamically from the execution of the ASP script on the server. While this is a simplistic example, you should get a sense of the power of this ASP capability. "Thanks" to Dave Kaplin at Microsoft for the explanation of this powerful feature in a thread from the Denali list server.
The question you are probably wanting to ask is "Where do I put what?" meaning how do you decide what scripts should execute on the client and which on the server. The answer is that most of the client procedures will usually deal with data validation. All of the other procedures, accessing data, communicating with host systems, will take place within the server-side scripts. There is no hard and fast rule. Experience is the best teacher in this case.
Remember that all browsers do not support VBScript, or scripting at all. If you want to provide client side scripting, be sure to interrogate the Browser Capability object to see which scripting language is supported. You can then return the appropriate client side scripts.
Java Script, REXX, and Other Scripting Languages
As discussed in the section "Changing the Primary Scripting Language," the default language of Active Server Pages is VBScript. Java Script is also supported by ASP "out-of-the-box." The OLE object model for scripting engines, which Active Server Pages supports, enables you to easily integrate other scripting languages and their associated engines into ASP.
The ability to host a variety of languages within the Active Server Pages environment is an incredibly powerful feature. If you are a developer with years of experience generating Perl scripts, there is no need to forgo all of that valuable knowledge. You can immediately become productive in ASP development. As you begin to learn VBScript or JScript you will be able to incorporate additional features such as dynamic client-side scripting.
REXX is one of the most widely used scripting/macro languages in existence today. It is available on platforms ranging from OS/2 to the AS/400 to the mainframe. There are even versions of REXX implemented today as visual languages. VisPro/REXX is one such example of a visual REXX environment. This OS/2 application provides an easy to use and incredibly powerful visual development metaphor, leveraging the REXX language. For more information about VisPro/REXX, point your browser to http://www.vispro.com.
For the countless REXX developers working in development today, the ability to plug a REXX scripting engine into Active Server Pages once again opens the gates wide to let the greatest number of people maximize their Inter/intranet development.
Selecting a Scripting Language for a Page
For those languages that follow the Object.Method syntax and use parentheses to enclose the procedure parameters, add the selected language using the LANGUAGE tag. The syntax of the LANGUAGE tag is:
<% @ LANGUAGE = ScriptingLanguage %>
Be sure to add this tag as the first line in your .asp file. If you want to change the default scripting language of all .asp pages, you will need to change the value of the DefaultScriptLanguage entry found in the NT registry to the new script type.
For languages that do not conform to the Object.Method syntax, you must add a registry key with the corresponding language name and value to the ASP\LanguageEngines registry entry. For more information on adding these types of scripting languages, see the "Using Scripting Languages" reference in the Active Server Pages documentation.
In this chapter, you have had your first taste of the way in which scripting and HTML are integrated within an .asp file to create dynamic content within a Web page. You have looked at the Visual Basic family and discovered its humble roots. You have also received an introduction to the major ways in which scripting and HTML can be united to form a greater whole.
In the remainder of this section, there are a number of chapters that cover the nuts and bolts of VBScript development. We have chosen to focus on VBScript over Java Script because VBScript is the native language of Active Server Pages. Also, for those of you coming to ASP development without the benefit of having worked with Visual Basic or VBA, you will get a good foundation of the shared language syntax and constructs that enable you to easily and quickly use the VBA or VB tools.
Here is what you can look forward to in the rest of this section:
© 1997, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.