Now that you have covered the basics of scripting, it is time to take a good look at client-side versus server-side scripting. Depending on the type of Web site you create, you may choose to do only client-side scripting or only server-side scripting. However, most likely you'll end up with some of both on your Web site. If you are trying to decide on which to use in your Web application, or if you're just wondering what the difference is between the two, then, read on. In this chapter you'll learn:
If you're thinking "One runs on the client and one runs off the server" then you're right, but there's quite a bit more to the story.
For years the World Wide Web was used primarily as a distribution medium for documents. The HTML language became a common format, which let the early adopters of the Web (colleges, and so on) share documents among a wide diversity of different hardware and operating systems. Recently, the business industry has turned its attention to the Web and has begun looking for ways to make HTML do things it was never designed to do.
Even though advancements in the HTML specification have given additional levels of formatting to Web documents, users were demanding the ability to make their Web pages "come alive." To meet this demand, Netscape and Microsoft added scripting languages (JavaScript and VBScript) to their Web browsers.
By adding Java and VBScript interpreters to their browsers, users were able to add scripts or mini-programs to their Web pages. This is accomplished by embedding script code (which is a small piece of programming logic) into existing HTML documents. Listing 26.1 shows a sample HTML page with a small VBScript embedded.
<HTML>
<TTILE>Sample VBScript Page</TITLE>
This is a sample page with small VBScript program embedded.
<SCRIPT Language=VBScript>
Msgbox "Hello World"
</SCRIPT>
</HTML>
If you load this page in Internet Explorer you will see the familiar (but useless)
"Hello World" appear in a message box. What's important about this is to
understand what goes on when the browser processes the HTML page. As the page is
loaded, the browser looks for the <SCRIPT> </SCRIPT> HTML tags. The browser
treats anything between these two tags as a script, and sends this information to
a script-processing DLL on your machine. Your PC compiles this script and executes
the program. Since this program is being compiled and executed on your local machine
(by your client browser) it is referred to as client-side scripting.
NOTE: Client-side scripting is covered in depth in Chapter 28, "Client-Side Scripting with VBScript."
Server-side scripting using Active Server Pages uses the same VBScript language that is used in client-side scripting. The difference is that with Active Server Pages, the script is compiled and processed by the Web server before the Web page is sent to your browser.
Server-side scripting will be covered in detail in Chapter 29, "Server-Side Scripting with VBScript," but here is a quick overview of how it works. Take a look at the HTML page in Listing 26.2.
<%
'Update Counter
Set FileObject = Server.CreateObject("Scripting.FileSystemObject")
CounterFile = "d:\inetsrv\wwwroot\counters\inkwell.ctr"
Set OutStream = FileObject.OpenTextFile (CounterFile, 1, FALSE, FALSE)
Count = OutStream.ReadLine
IF Count <> "" THEN
Count = Int(Count) + 1
ELSE
Count = 1
END IF
Session("Counter") = Count
Set OutStream = Nothing
Set OutStream = FileObject.OpenTextFile (CounterFile, 2, FALSE, FALSE)
OutStream.WriteLine CStr(Count)
Set OutStream = Nothing
%>
<HTML>
<TTILE>Sample Page with Server Side Script</TITLE>
Welcome to our site, you are visitor number <%=Session("Counter")%>
</HTML>
When you load this page in your browser, ASP looks for the <% %> tags, which tell the Web server that this is a script to be run on the server. In Listing 26.2, the Web server opens a text file called INKWELL.CTR. It reads a line from the text file and stores it into a variable called count. It then adds one to count and stores the answer in a session variable called Counter. The new counter is written to the text file, the file is closed, and the Web page is sent to the browser.
Notice the text you are visitor number <%=Session("Counter")%>. When this string is sent to the browser, <%=Session("Counter")%> is replaced with the number from the variable. In this way, HTML pages are updated dynamically by ASP. This is a major advantage of server-side scripting and provides one of the first components to creating true Web applications.
You'll find many advantages and disadvantages in each of the scripting methods. The remainder of this chapter will describe those advantages and disadvantages in detail and give you the information you need to decide how to employ each in your Web site.
Client-side scripting has many advantages. In the early days of computing (after punch cards, but before PCs), all processing was done on mainframes, and our interface to the system was via a dumb terminal. We would issue job commands via the keyboard and see program output on our screens, but all the processing was done on the mainframe. A tremendous paradigm shift took place with the introduction of the PC to the business market. Now we had intelligent terminals on the desktop, and processing tasks were moved to the PC. Our mainframes took on a different role as an information warehouse for our data. So began the age of client-server computing.
And then came the Web, promising to revolutionize computing but at the same time taking us back to the old ways of computing. Our PCs with Web browsers have become the new dumb terminals, and our file servers have again been given the mundane tasks of gathering and validating user input, massaging data, and returning reports to the user. For Internet computing to become synonymous with client-server computing, a new technology was needed. The answer: client-side scripting.
Look at today's typical Web-based form. You have designed a screen that asks users for their names and ages. A visitor to your page types his name properly, but types in "twenty-four" for his age instead of the number "24" (Even though the space on the screen is only three characters wide). Here is what happens behind the scenes. When the user presses the Submit button on the form, his name and his age ("twenty-four") are sent over his modem across the country to your Web server, where there is a program (maybe a CGI script) waiting for his input. Your program is expecting to get good data from the user and is ready to add it to the database. But instead, it gets this big string of alphabetic characters for the age. So your Web server (if you remembered to add error checking to the program) creates an HTML page that asks the user to enter a valid age and sends this page back across the country to the user's browser. The user will hopefully complete the field correctly the second time and send the data back to your server again.
This whole process may take just a half a second, or several seconds, depending on several factors (the speed of the user's connection, the speed of the Net, your Web server's load, and so on). This is not what you call a rich user experience--and what a waste of resources.
This is a typical process that happens millions of times a day, eats up bandwidth on the net, and uses your Web server CPU time to validate the input of a user. This validation could easily have been done on his local PC.
Moving these simple validation tasks from the server to the client is a simple task and is a big advantage of client-side scripting. If the Web page above had a simple validation script (which you'll see more of in Chapter 29) then the user would be immediately notified of his data entry error, and more importantly, the page would not have been sent to the server until it was validated and complete.
Client-side validation is one of the first processing tasks that you will perform with scripting. But VBScript is a powerful language, and with a little programming you can do very complex processing right inside your user's browser.
Your goal should be to keep the processing as close to the source of data as possible. What this means is that data input by your user should be processed and prepared as much as possible on the client before it is sent to the server. The opposite is also true--if the data source is a database on your Web server, you should do the bulk of the processing of that data on the server before it is sent back to the user's browser.
Even though VBScript is a powerful language, you'll soon find some function you want or need that VBScript does not provide. When you reach this point, it's time to start using ActiveX controls.
ActiveX controls are small software components that will add specific functions to your programs. There are hundreds of different ActiveX controls that provide a large diversity of programming functionality. There are small, simple controls that allow you to create an animated button on your Web page, and large, complex controls that will allow you to add unlimited charting to your applications.
ActiveX is important to client-side scripting because these controls can be downloaded
and installed on your user's machine by his browser, and these controls can be completely
controlled with client-side scripting.
NOTE: For more information on ActiveX Controls, see Chapter 14, "Multimedia Pages with Visual InterDev Controls," Chapter 15, "Data-Aware Pages with Design Time Controls," and Chapter 16, "Live Forms with Microsoft Forms 2.0 Controls."
For a good example of what can be done with Web pages and ActiveX controls, visit http://www.microsoft.com/activex. This site has dozens of ActiveX controls you can download, and has links to other ActiveX sites on the Web. You'll find it's also a great place to get ideas on how to "Activate your Site" with ActiveX.
The days of static Web pages are nearing an end. Web users are demanding live, interactive Web pages. With the introduction of Visual InterDev, you have all the tools you need to create exciting and entertaining Web content.
Learning client-side scripting is an important step in creating interactive Web pages. To create a high-quality Web site, you need to interact with users, not just present them with information. You'll do this by using VBScript to ask the user for information, and then create a custom Web page based on their input. This "dynamic" page will give them just the information they want, in a format specifically designed for them. That's interactive!
See Chapter 28, for specifics on client-side scripting.
As you look at the advantages and disadvantages of client-side versus server-side scripting, you'll find many areas where one method is much better equipped than the other. manipulating the user interface is one of these areas. Server-side scripting can do very little to modify the user's interface, but client-side scripting offers you a wealth of options.
The HTML document itself provides much of the interface that your Web users see. With client-side scripting, you can control much more than just the appearance of the document. The MsgBox and InputBox functions give you an easy way to provide the user with feedback or gather additional information for the user. But you see the real power of interface control when you realize that the browser itself is an ActiveX control that can be controlled with VBScript.
Using VBScript you can put a custom message in the status bar, open a new browser
window, resize the window, or change color; you can even hide the toolbar, status
bar, and menu (which users really hate, especially when you forget to turn them back
on).
NOTE: See Chapter 28 for examples on how to control the user interface with client-side scripting.
Having a good front-end interface is important in any database application. When creating Web applications for a large diversity of users, creating an interface that is intuitive and easy to use is an absolute necessity. Most applications on the Web today use static forms, meaning that the user is presented with a single form that must be completed in its entirety and then submitted to the server.
Client-side scripting allows the creation of dynamic forms. These forms change dynamically, based on input from the user. Suppose you are designing a patient record form for a medical firm. One field on the form would be a yes/no question to ask if the user is currently taking any medication. If she answers yes, then the form would want to know what types of medications she is currently using. Using a static form, the user would be presented with the yes/no question, and even if she answered no, she would have to tab past all of the input boxes regarding the types of medication. The same question built with client-side scripting would show the users only the yes/no question. If the user answers "yes," then all the additional fields would be shown, but a "no" response would skip directly to the next question.
Dynamic forms are much more sensitive to users' needs and are easy to create with client-side scripting.
How many times has this happened to you? You visit a Web site to pick up a new beta software product you've heard about. Of course, the software vendor wants you to complete a registration form before he gives you access to the download page. You see twenty fields in front of you, asking your name, address, and so on. Being an Internet-savvy user, you fill out your name and e-mail and leave everything else blank. (You just want to get the software, not get on a mailing list). Now you hit the Submit button and wait for the download page to appear. Minutes go by (actually just a few seconds, but it seems like minutes) and you get a screen back that says, "sorry, but you must enter your phone number." You enter the phone number and press Submit again. This time it comes back "sorry, but you must enter your zip code." This time you look carefully at the input screen and you see that all the required fields have an asterisk on them, so now you complete the form and finally get to your download page.
With client-side scripting, this needs never happen. On a well-designed Web form, you can validate the fields the instant the user presses the Submit button (or even sooner, as he leaves the field). The client-side script can pop up a message box, telling the user what's wrong with the input, and then move the cursor to the offending field. Best of all, this is all done on the client, so feedback to the user is instantaneous and the page is not uploaded to the Web server until it is complete.
Client-side scripting is a major advance in Web technology and one day will play an active roll in every Web site. As a Web pioneer, you'll be one of the first to deploy client-side scripting. It has always been true that pioneers are the first to reach the gold, but there were also a lot of those early pioneers who ended up with arrows in their backs. A good understanding of the disadvantages of client-side scripting will help you find your way on the new frontier.
When the great browser war is finally over, someone will be declared a winner. But the casualties of this war could be the Web developers like you. Microsoft and Netscape are the two dominant players in the browser battle and, with each new version, new features are added that make designing Web pages easier and more difficult at the same time.
Extensions to the HTML language are designed to make programming interactive Web content easier, but competing standards between Microsoft and Netscape make creating a universal Web page a near-impossibility. Currently, to design a highly interactive Web site usingöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþBScript or ActiveX. A Netscape plug-in from NCompass is available to add VBScript and ActiveX support to Netscape. But not only does this add-in cost nearly $100, I've also never seen anyone with a highly interactive site built using VBScript be able to make their site function using Netscape with the NCompass plug-in.
Hopefully Netscape will soon add support for VBScript in its browser. This will make it much easier for web developers to create a universal web page. This would have made our last large Internet development project a lot easier. We created a highly interactive site called NameCard (www.namecard.com). To make it Netscape-compatible, we created two separate sets of all the interactive Web pages. We detect the type of browser the user is using when they visit our home page, and then we redirect them to the pages appropriate for their Web browser. This not only added hours to our Web development efforts, but also doubles the maintenance of our site.
If you are developing for an intranet site, and all of your users are on the same browser, then this will not be a problem for you. But if you are developing for the public, you need to write pages for a variety of browsers.
If you think that Netscape is the only company making your life difficult, think again. Microsoft will throw a few challenges your way too.
As I mentioned above, when we first added Netscape support to NameCard (www.namecard.com), we sent users to one site if they were using Netscape and to another site if they were using Internet Explorer. We quickly discovered a new problem; there are several different versions of Internet Explorer.
We knew if someone tried to use Internet Explorer Version 2, she would not be able to use our site, but we forgot about Internet Explorer 3 for the Mac and Internet Explorer 3 for Windows 3.1. Although these versions have full support for VBScript, they do not support ActiveX controls (Especially the 32-bit variety we were using in our site).
The moral of this story is, just because someone is using Internet Explorer, it does not mean she has full support for all features that are available in Internet Explorer 3 for Windows 95 and NT. So when you design your pages, keep this in mind. If you are using an ActiveX charting control, then Macintosh users won't be able to see öþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþing the coolest Web page of your life. You have 800 lines of VBScript that took days to debug. You put them online and wait for your users to marvel over your genius. Two days later, Leroy the Lowlife visits your site, right-clicks in his browser window and chooses View Source. All your hard work pops up in his Notepad and he quickly makes a page that looks just like yours. How does this make you feel?
Welcome to the world of client-side security. This is one of the major disadvantages of client-side scripting. Since client-side VBScript is compiled and executed on the client machine, the source code is sent to the browser in plain text.
When you are learning VBScript, this is great--every time you visit a site, you can click View Source and see just how they did that. But for the developer who wants to protect intellectual property rights, it's a real nightmare.
One day soon, there will be a way to send down precompiled or encrypted text to the Web browser. Until that happens, the best bet is not to include anything in a client-side script that you do not want someone to see.
On a humorous note, I visited a site one day that said "You must enter a password to access this site" and had a text box waiting for a password. I clicked View Source and saw something similar to Listing 26.3.
If txtPassword = "hal" then window.location.href = "users.htm" else msgbox "Invalid Password" end if
After I nearly fell off my chair laughing, I typed "hal" and checked out this lame site. Not much security in client-side scripting.
This is not a major nuisance but it is something you need to be aware of. All client-side scripts are simply embedded text programs inside traditional HTML pages. Even though this script is not shown in the browser, it takes about the same time to download as any other element on the HTML page. It also has to be downloaded in its entirety before it can be executed. This is one of the few times in programming where you may not want to add lots of unnecessary comments to your source code.
To make your pages download as quickly as possible, follow these guidelines:
This disadvantage is a big nuisance and a good reason to use server-side scripting. We call this behavior local scope, which basically means that we can use any information we gather about a user while he is on the same page, but when he moves to another page, all the information is lost. Even though you can have private and public variables in your Web page, there is no easy way to store variables generated from one page and access them from another page in a client-side script.
Traditionally, we used cookies (which is a server-side variable) to store information
about a user as he moved from page to page. Session variables and server-side scripting
make cookies obsolete and are an easy way to give your variable application scope,
instead of local scope.
NOTE: Session Variables are covered in detail in Chapter 30, "Server-Side Scripting with VBScript."
This is one of those advantages/disadvantages all rolled into one. The reason it is listed here as a disadvantage is because ActiveX controls can be large and take a very long time to download over a slow connection.
Let me give you an example. When you do a full install of Internet Explorer 3, it installs an ActiveX control called the HTML Layout Control. This is a super control, but is about a megabyte when you have to download it. If a user does a partial install of IE3, then this control is not loaded onto the user's machine.
In designing the NameCard site, we made extensive use of the HTML Layout Control. If I send you my NameCard, and you do not have the HTML Layout Control installed, then your browser will try to download and install it as soon as you click on my NameCard. So if you did a full install of IE3, then my business card will pop up on your screen in about five seconds; if you did not do the full install, then you may have a fifteen-minute wait while the control is downloaded and installed on your PC.
So the secret is to keep your ActiveX controls as small as possible, and use them
only when you need to. On the positive side, the ActiveX control needs to be downloaded
only once. The next time the user needs the control, it's already available on his
machine and the access is instantaneous.
NOTE: This is one of the big disadvantages of creating controls with VB5 CCE. The VB virtual machine is nearly 1M in size and most users will not have this already installed on their system. That means if you write a nice little 20K ActiveX control in VB5, your Web visitors may have a long wait to load your page.
Since ActiveX controls have direct access to the operating system, you could easily create an ActiveX control that did some nasty things to your client's PC. For this reason, when Internet Explorer is in its default safety mode, it will not download any ActiveX controls that are not digitally signed.
This means that, as a control developer, you need to apply for a digital certificate
from a certificate agency. You use the digital certificate to "sign" all
the controls you create. This is basically a warranty that tells users who created
the control, and is your promise that your control will not do anything harmful to
their system. Here is an example of my digital certificate (see Figure 26.1).
Figure 26.1
An example of a digital certificate issued by Verisign.
If you do not digitally sign your controls, your users will see a message similar
to Figure 26.2 when they try to use a page that contains your ActiveX control.
Figure 26.2
A warning message shown to users when they view pages with unsigned ActiveX controls.
This message will scare even an experienced user, and worst of all, most users will
not even be able to use your page.
When you develop a control, you have the option to mark the control as "Safe for Scripting." This means that your control is safe no matter what type of script you use it in. You may not be able to mark a control as safe even if you develop it. Let's say that you create an ActiveX control that stores your program's data into the user's Registry. If you create the control so that it can write any entry in the user's Registry, then you cannot mark it as safe. This is because someone else can write a script that puts bad information in the Registry and disables the user's machine. They can even use your control to do it. Scary, isn't it? The best rule of thumb on safety to follow is to make the control do only what you need it to do.
The code signing process is not difficult, and the certificates are fairly inexpensive--for example, $20 a year for a personal certificate and $400 a year for a commercial certificate. But it takes at least a week to get a certificate, and it does add some expense and time to your Web development project.
This is one of those disadvantages that seem to be taking care of itself. The more complex your VBScripting becomes, the more important it is to have good debugging tools to help you polish your code. As we first made the move from Visual Basic to VBScript, one of the first things you missed is your Visual Basic IDE. Microsoft spoiled us by providing an excellent editor for Visual Basic, which includes color-coded text, inline syntax checking, and integrated debugging. Then they deliver VBScript, and we are back to writing our source code in Notepad.
Things are changing fast in the Internet world, and now Visual InterDev again provides you with an excellent editor. Microsoft has just released a beta version of a script debugger. This debugger is presented in more detail in Chapter 29, "Client-Side Scripting with VBScript." As far as debugging goes, it's still pretty limited--no watch windows, no conditional breakpoints--but it is still light years ahead of having no debugger at all.
Using the script debugger you can single-step through your code (this is a lot better than the MsgBox ("got here") we had been using), and it's integrated right into Internet Explorer. Just click View Source from your menu, and the debugger appears, waiting for your command.
One of the last and most dreaded parts of programming any application is handling run-time errors. The reason this is such a problem is that you have to anticipate every possible action a user might do while using your product. For example, you might ask the user to input the color of her hair, and she will instead enter -1. Or when the user is supposed to press the Submit button, she presses the Insert key. By now you're getting the picture. You must set up your program to operate correctly not only when things go right, but also when they go wrong.
VBScript has an On Error statement just like Visual Basic, but it has only the On Error Resume Next statement and is missing the familiar On Error Goto ErrHandler. This limited error handling means you have to use the VBScript Err object, instead of using traditional error handling we are familiar with from Visual Basic.
Error handling is one of the final pieces of application development and is usually fine-tuned during the testing phase of development. VBScript's limited error handling will not keep you from doing anything you want your application to do. However, it may add a few painful hours to your development cycle.
You will have a wide variety of users visiting your site with a large diversity of computer settings. When you design a beautiful screen that looks great in 800x600 mode, it may be off the screen for users visiting your site in 640x480 mode. Listing 26.4 shows a server-side script that will read in the screen mode.
Session("VideoRes") = Request.ServerVariables("HTTP_UA_PIXELS")
This will store 800x600 into a session variable called VideoRes. This is a big help,
but unfortunately there is no way currently to read whether the user is running "800x600
small fonts" or "800x600 large fonts." The user's font setting will
make a big difference in how much screen real estate you have to deal with.
A good rule of thumb is to design your site for 640x480 with 256 colors. This setting will work for most users. The other option is to read the screen mode, as shown above, and change your screen elements with client-side scripting.
When you start creating applications in VBScript you will really miss all the VB commands that were removed from the language to keep VBScript safe. Even though this can be remedied with ActiveX controls, having no access to file and system objects makes many tasks which are simple in VB nearly impossible with VBScript.
Probably the most difficult task is storing local information for your application on your user's machine. In Visual Basic, you can just open a file and write information to it. With VBScript, you cannot create a file, write to a file, or even tell if a file exists on a user's machine.
Any commands that could possibly harm a user's machine (or just make changes to it) have been removed from VBScript. You cannot read and write from an INI file or the Registry. You cannot change the user's Windows settings (screen resolution, color mode, and so on).
As a developer, what this means to you is that you have to create an ActiveX control to interact with the client's file or system objects in any way.
As you can see, there are lots of benefits to using client-side scripting, but also several drawbacks. Before you decide on what technology to use in your site, you'll need a little more information on server-side scripting. It's coming up next.
You have probably been hearing a lot about server-side scripting lately. Now you're going to hear even more, because server-side scripting is awesome.
Server-side scripting has been around for quite a while, in the form of CGI and PERL scripts. Nearly all of these scripts which are running on the Internet today have been dedicated to tasks of processing HTML forms and sending text back to the browser. With the introduction of Active Server Pages as an integral part of IIS 3, and the introduction of Visual InterDev, server-side scripting has taken a giant leap forward.
Chapter 30, "Server-Side Scripting with VBScript," will be covering server-side scripting in great detail. In this section, you'll learn a few of the tasks server-side scripting can and can't do, and by the conclusion of this chapter, you will have a much better understanding of when and where to implement this exciting technology into your Web site.
One of the great advantages of using server-side scripts is that they are entirely browser-independent. Unlike client-side scripts, which are dependent on the user's browser, server-side scripts are processed entirely by your Web server.
When a server-side script executes, it has many functions it can perform. One of the most important is sending formatted HTML back to the browser. This allows you to modify HTML pages on the fly before they are transmitted to the client. This is usually done to create dynamic pages based on a user's preferences. However, you are not limited in sending back only HTML. Server scripts can send back binary information, set cookies, and even return VBScript code and object tags to the browser (but since VB code you send back is executed by the browser, this method is not browser-independent).
When we converted an Internet-Explorer-only site to be compatible with Netscape, we quickly discovered that we could move many of the functions we were doing with client-side scripts to the server. A good example of this is a VBScript program we were using to validate credit cards. In VBScript this was easy to do on the client, but this client function did not work in Netscape. We simply took the exact VBScript code and moved it into a server-side script. Then when the Netscape user submitted his form, we were able to validate his credit card using VBScript running on the server. This was not as efficient as running the script on the client, but it was a lot quicker than trying to rewrite the code in Java, and the server-side solution works with any browser.
One of our big gripes in client-side scripting is that there is no easy way to keep variables as a user moves from page to page. Server-side scripts put a quick end to this problem. Active Server Pages has a Session Object that will let you create session variables. Creating a session variable takes just one line of code, as is shown in Listing 26.5.
Session("UserName") = "Jim"
Once this variable is created, it stays active as long as the user has an active session to your site. This is one of the first tools that have really made the creation of Web "applications" a reality.
Using session variables, you can let your user go from screen to screen, making choices and providing you with input. Each screen can store the data collected into these session variables, and once the data entry is complete, you can use all the variables you have set to update a database or create a report for a user.
To see a great example of this on the Web, take a look at the NameCard design wizard on www.namecard.com. This wizard first displays an input screen to the user. He then provides his name, address, and so on, to be included in his online business card. This information is stored in session variables. As the user progresses thorough this wizard, he gets the opportunity to chose a custom icon, pick his own font style, choose a custom layout for his business card, and so on. Once all the data entry is complete, the NameCard site creates a single SQL statement from all of these variables (see Listing 26.6) and updates the database with a single call.
SQL = "INSERT INTO card (company, title, name,
address1, city, state, zip, country, phone1, phone2, email, slogan, Web_site_url,
card_key ) "
SQL = SQL & "VALUES ("
SQL = SQL & chr(39) & Session("CompanyName") & chr(39) &
","
SQL = SQL & chr(39) & Session("Title") & chr(39) & ","
SQL = SQL & chr(39) & Session("YourName") & chr(39) & ","
SQL = SQL & chr(39) & Session("Address1") & chr(39) & ","
SQL = SQL & chr(39) & Session("City") & chr(39) & ","
SQL = SQL & chr(39) & Session("State") & chr(39) & ","
SQL = SQL & chr(39) & Session("Zip") & chr(39) & ","
SQL = SQL & chr(39) & Session("Country") & chr(39) & ","
SQL = SQL & chr(39) & Session("Phone1") & chr(39) & ","
SQL = SQL & chr(39) & Session("Phone2") & chr(39) & ","
SQL = SQL & chr(39) & Session("Email") & chr(39) & ","
SQL = SQL & chr(39) & Session("Slogan") & chr(39) & ","
SQL = SQL & chr(39) & Session("HomePage") & chr(39) & ","
SQL = SQL & chr(39) & Session("CardKey") & chr(39) & ");"
Conn.execute(SQL)
You've just learned how easy it is to create session variables with server-side scripting. One of the things that make these variables really useful is your ability to build pages dynamically based on these variables.
There are many ways to use this to your advantage to add spice to your site. First, you can include these variables directly inside your HTML text. Notice the session variables in Listing 26.7. This is the form definition for a standard HTML form. Because the session variables are included, the fields are automatically filled in with the user's information any time this page is displayed.
<form action="nsdes.asp" method="post"
name="form1">
<div align="left"><table border="0" cellpadding="2"
cellspacing="0" width="600" bgcolor="#80FFFF">
<tr>
<td><font size="2" face="Arial"><strong><u>Your
Name:</u></strong></font></td>
<td colspan="3"><input type="text" size=40 maxlength=50
name="txtyn" value="<%=Session("YN")%>"> </td>
</tr>
<tr>
<td><font size="2" face="Arial"><strong>Company
Name:</strong></font></td>
<td colspan="3"><input type="text" size="40"
maxlength=50
name="txtcn" value="<%=Session("CN")%>"></td>
</tr>
<tr>
<td><font size="2" face="Arial"><strong>Your
Title: </strong></font></td>
<td colspan="3"><input type="text" size="40"
maxlength=50
name="txtti" value="<%=Session("TI")%>"></td>
</tr>
<tr>
<td><font size="2" face="Arial"><strong>Address:
</strong></font></td>
<td colspan="3"><input type="text" size="40"
maxlength=50
name="txtA1" value="<%=Session("A1")%>"></td>
</tr>
<tr>
<td><font size="2" face="Arial"><strong><u>Email:
</u></strong></font></td>
<td colspan="3"><input type="text" size="20"
maxlength=60
name="txtem" value="<%=Session("EM")%>"></td>
</tr>
</table>
</div>
</form>
In addition to embedding variables in HTML text, you can also create HTML text based on these variables. See Listing 26.8, which includes an image on the page only if the user has a resolution that is higher than 640x480. (This method was used to allow all the menu choices to appear on screen when the user had only 640x480 resolution.)
<%If Session("VideoRes") <> "640x480"
then
Response.write "<td><p align=right><img src=images/LOGO.GIF width=189
height=117></p></td>"
end if
%>
You can also redirect the user to different pages based on their input (see Listing 26.9).
<%If Session("Option") = "Beginner"
then
Response.redirect "newuser.htm"
Else
Response.redirect "normal.htm"
end if
%>
These are just a few of the methods for creating dynamic Web pages with server-side scripts. You will find dozens more as you put ASP to work for you.
Server-side scripts are much more secure than client-side scripts. This is because
everything between the <% %> tags is processed by the server and never returned
to the browser. Only the results of the server-side script are sent to the browser,
never the script itself.
TIP: For an additional level of security, move your server-side scripts to a separate directory from your other Web pages, and if you are using NTFS, only enable "execute" permission for these files to the IUSR_MACHINENAME account.
Server-side scripts have many methods of communicating with server databases. You can find many of these techniques in Chapter 29, "Server-Side Scripting with VBScript," and Chapter 33, "Database Development with Visual InterDev," so we won't cover this in detail here, but since this is a major advantage of server-side scripting, it deserves to be listed here.
What is important for this topic of discussion is that server-side scripts handle all database processing. The client scripts will gather information from the user and send them to the server for processing. The server will process the data and return results to the client.
This is an often overlooked, but super feature of server-side scripts. Server-side scripts can use ActiveX objects too. Because server-side scripts have no control over the client interface, you cannot expect to call the MSChart control on the server, and have a graph appear in the user's browser. There is an unlimited number of uses for server side ActiveX controls. These controls do not need to be downloaded to the client to be used.
Several server-side ActiveX controls come with IIS 3 and Visual InterDev (ADO, FileSystem, Ad Rotator). These controls are easy to use and ready to run, but you can also create your own ActiveX controls to use on the server. When we created the NameCard site, we found that there was no easy way to store and retrieve images in an SQL database using ASP. To answer this need, we wrote an ActiveX control in VB5, and called it directly with our server-side script.
We all have the need for speed. ASP scripts run much faster than their CGI and PERL counterparts. This is mainly due to the fact that the scripting DLL used by ASP is already loaded in memory, waiting to run your scripts. CGI programs are normally separate EXEs that are loaded from disk every time they are needed.
Speed is a great benefit, but once you start writing ASP scripts using Visual InterDev, you'll never want to write another CGI program anyway.
There are many HTTP server variables that your Web server and your client's browser communicate between each other. These variables hold everything from the IP address of the user (REMOTE_ADDR) to the type of browser being used (HTTP_USER_AGENT). You will find numerous uses for this information, and it is readily available to your server-side script.
For a list of all available HTTP server variables with an example of their use, refer to the document named , which is installed on your machine when you install ASP.
The Browser Capabilities component is included with ASP, and provides you with a description of the capabilities of the client's browser. You will need this component until the great browser war is over.
Using this component, not only can you determine whether the user has Internet Explorer or Netscape, you can determine the browser's version number, whether it supports Java or not, whether it supports ActiveX, VBScript, tables, frames, sounds--you nöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþöþed to be aware of.
Server-side scripts can easily alter what the user sees by sending back custom HTML text using the Respose.Write method, but you have no direct control over the user's interface. You cannot call the MsgBox function from a server-side script (even though you will try this a few times by mistake).
This is not a big disadvantage, but it will cause you some headaches. Consider the following. A user fills out a form and submits it to your Web server. Your server-side script looks up the user's ID in your server's database and finds out that the user entered an invalid ID. What you want to do is to have a server-side script that looks like Listing 26.10.
<%`Bad ID Entered
MsgBox("Invalid User ID")
Response.redirect "input.asp"
%>
But this doesn't work, because you cannot talk to the user interface (script will give you an error on MsgBox). So what you will end up doing is setting a session variable with the server script, and communicating with the user in a client-side script (see Listing 26.11). What a pain.
<%`Bad ID Entered
Session("ID") = "BAD"
%>
<SCRIPT Language="VBScript">
if "<%=Session("ID")%>" = "BAD" then
Msgbox "Your ID is Invalid" & chr(10) & "Please ReEnter",16,"Bad
ID"
window.location.href = "input.asp"
end if
</SCRIPT>
The more complex your scripting becomes, the more important it is to have good debugging tools to help you polish your code. Server-side scripting currently has no debugging tools available at all. The recently introduced script debugger currently works only with client-side scripting.
You will have to debug your code the old-fashioned way, by using Response.Write("got here"), or just run your scripts and see which lines the execution stops on.
I expect to see an integrated debugger appear for server-side script soon. We'll keep our fingers crossed.
You already know about session variables, and that a new session is created every time a user visits your site. But what about when a user leaves your site? Good question, and for most applications, the session will just sit there until the session timeout expires.
There is a Session.Abandon method, but knowing when to call it is very tricky. The user can enter a new URL in his browser at any time, never to return to your site. For this reason, there is a Session.Timeout property that clears a session after a specified amount of inactivity from the user. This timeout is 20 minutes by default, but can be changed in the Registry.
I've seen firsthand how the session timeout can cause some unexpected problems. When we first brought up our NameCard service, we noticed that occasionally we would get a record written to our database that was nearly all blank. After much head-scratching, we discovered that sometimes a user would start the NameCard design process, then when it gave him the option to upload an image, he would spend a half hour trying to scan in a photo he was happy with. Once he had the photo ready, he would Alt-Tab back to his browser and continue the NameCard design process. Unknowing to him, and us, his session had expired and all the session variables were now empty. When he got to the final stage of the wizard and the database got updated, it had only the items that he'd set after the timeout had expired (because a new session had been created for him).
We understand the importance of script safety, and have no problem with the deletion of file I/O from client-side scripting, but server-side scripting is a different story. Are you going to write a server-side script to format your hard disk? I don't think so.
VBScript for the server should have every possible command at your disposal. Why can't we read and write binary files? Why can't we call API functions? And what about DoEvents? What did the DoEvents command ever do to hurt anyone?
If you are already a VB developer, you'll find yourself crying every time one of your favorite little VB keywords pops up with a syntax error because it is not available in VBScript. Version 2 of VBScript was just introduced, and many new keywords were added, but until VBScript has a much closer feature set to VB, we will all be writing lots of custom DLLs and ActiveX controls to provide the functions that VBScript had.
Now for the big question, which one should I use? If you skipped right to this page without reading the rest of the chapter, you really need to browse through the advantages and disadvantages before you make your decision.
Your Web site can use only client-side scripts, only server-side scripts, or a mixture of both. Every site is unique, so your first priority is to decide what features are "must-have" and what features are "nice-to-have" for your site.
Once you have your goals in mind, you need to consider some of the following points before you begin integrating scripting into your Web site. Take a look at the following items and determine which ones are most important to you:
Once you've determined what type of scripting you are going to use on your site, get started on your Web development. And don't worry if you make mistakes--you can write version 2 of your Web page next week. You won't even have to send out floppies to upgrade your users.
Now that you have a good understanding of the differences between client-side and server-side scripting, it is time to focus your attention on the details of implementing them in your Internet/intranet development strategy.
The following chapters will give you the details you need to become a master of InterDev scripting.