So far, the discussion of VBScript has focused solely on the scripts that relate to the page running on the client computer without much regard to the Web server. The server has another role that goes beyond just downloading pages or components. VBScript code in a page can, in some cases, certainly affect what happens on the server. Understanding this role can be just as important to deploying full-fledged active Web page solutions as understanding VBScript fundamentals. Client-side validation of server-bound data and server-side application processing in response to that data is the topic of the second half of today's lesson.
The pages that are downloaded from a server to your client computer often are intended to serve simply as front ends for collecting data. The data is then provided to the server for storage or subsequent processing. It might seem at first that VBScript is just a periphery player in the server-side communication because so far, this book has focused on how you can use VBScript for stand-alone pages independent of the server. However, VBScript can serve as the basis of the front end for data validation and final submittal of the data to the server to ensure clean data and thereby enhance server performance.
Today's lesson will cover the server front-end and back-end arrangements in enough detail that you understand all the issues involved. You will see how to validate form data in your script and how to initiate the submission of form data to a server within your script. You will probably encounter your own situations where you will need to write scripts that interact with the server. Today's lesson will show you how to do it successfully with an awareness of the big picture.
For some time, HTML has had a model for collecting data on a page and submitting it to a server. Although that model is evolving with the help of technologies such as VBScript, the concepts are still much the same. Input control fields collect data from the user. Two specific HTML definitions are required for the page to submit that data to a program on the server. The input controls must be defined within a form so that the data from them can be submitted together as one data set. Some specific action must trigger the submittal, which is accomplished through an input control that is similar to a regular command button but has a type of submit.
Consider the form definition further. When the data is provided to the server, the server must be able to tell which program to submit that data to. After all, the server can't just assume the data should be added to a database or saved in a file or ignored. That is why the form tag has an ACTION attribute, which specifies the program on the server that processes the input from the client. These server-side programs that process page data in the past have commonly been called scripts. In addition, the form tag definition sets a method attribute to indicate how the information should be passed from the client back to the server.
All the details of this interaction are beyond the scope of this
book, but it is important to have a feel for some of the technologies
involved. In the past, the primary protocol for supplying data
back to the server and launching a script was CGI, or Common
Gateway Interface. This is still in broad use today. In addition,
another technology called ISAPI, or Internet Server Application
Program Interface, is rapidly emerging. This approach can be much
faster than CGI on Windows systems because an ISAPI-launched program
works in the same address space as server software. What this
really means is that it can be significantly faster. A related
technology called IDC, or Internet database connectivity,
can even result in direct database interaction through the use
of a template file.
| Note |
You can also use VBScript on NT Server with the Internet Information Server Web server software. The focus of this book is illustrating its use through the browser, so this topic is not considered in detail here. However, the same VBScript core syntax rules and language fundamentals that we have covered here apply in that environment as well. |
Although there are technical differences in the way these approaches are implemented, the concept is the same from the standpoint of your page and your code. When the user clicks a submit button on the form, the browser submits all the input fields on the form as well as the action parameter back to the server. The server activates the specified application and provides the field names from the form and their associated data to it as well.
It is then up to the application to respond to the request. Typically, the CGI or ISAPI application on the server might store the information from the page into a database. It might also generate another page to download to the client. These tasks are accomplished with assistance from the Web server. Typically, the CGI or ISAPI application will generate one long string for a page. This string contains all the tags that make up the Web page to be sent to the client. The server takes care of passing that data through the HTTP protocol back to the client. All this interaction happens fairly transparently to the user. From the perspective of the end user, she supplies some data and submits it, and suddenly, another page appears.
Some examples can help illustrate the process and also lead to the specific way that VBScript comes into play. First consider Listing 19.1, which shows a simple form definition on a page.
Listing 19.1. Form definition.
<form name="frmOrder"
action="/scripts/oleisapi.dll/Order.clsOrder.ProcessOrder" method="GET">
Your Name: <input name="txtName">
Street Address: <input name="txtAddress" >
City: <input name="txtCity">
State: <input name="txtState">
Zip: <input name="txtZip">
<input name="cmdOrder" value="Submit Order"type="submit">
</form>
| Note |
Usually, the data in the form would be presented in a more visually attractive format, such as with each element placed in the cell of an HTML table. For the sake of simplicity, the example is shown without any of these frills. |
Note that a submit button is defined at the bottom of the form. When the user selects the submit button, the browser automatically submits the form to the server. No VBScript code or any kind of code is required to make this happen! This is part of the HTML form and submit element definition. The server will receive data that includes the string /scripts/oleisapi.dll/Order.clsOrder.ProcessOrder. Also appended to this string is other information about the contents of txtName, txtAddress, txtCity, txtState, txtZip, and the form method attribute. The string /scripts/oleisapi.dll/Order.clsOrder.ProcessOrder tells the server to pass this request to the ISAPI OLE automation director, /scripts/oleisapi. (OLE automation is a method of communicating that some applications, including those generated by Visual Basic 4.0, can respond to.)
oleisapi is actually a dynamic
link library on the server system. oleisapi
starts the requested program. It can locate the requested program
because it is registered in the system registration database as
an OLE automation server. Order.clsOrder
specifies the DLL name and class of the program intended to handle
this request. ProcessOrder
specifies the method of this program that will be initiated. oleisapi
initiates the Order.clsOrder.ProcessOrder
method, passing it two important parameters. The first is the
data from the Web page in one long string. The second parameter
is used by Order.clsOrder
to supply a return page that oleisapi
will direct back to the server and subsequently back to the client.
| Note |
This discussion focuses on an NT Server Web server solution, but the general concepts will largely apply to other environments as well. |
Listing 19.2 shows the code for the Order.clsOrder.ProcessOrder method. This is Visual Basic 4.0 code, not VBScript. I show it here because it gives you a good, representative idea of what a server-side application might do with data from a page.
Listing 19.2. A server application called in response to page form submittal.
Public ProcessOrder(strRequest as String, strResponse as String)
Dim strName as String
' Extract the name from the data that came from the page
strName = GetNameField (strRequest)
' See if a valid name was supplied
if len(strName) = 0 then
' Name is missing, can't process the order.
' Generate a page scolding the user
strResponse = <html><head><h1>The name is missing!</h1>" & _
</head><body><p>Please supply a valid name with the order!" & _
</body></html>"
else
' Store order info from page in database
StoreInDB (strRequest)
' Generate a page confirming to the user
strResponse = <html><head><h1>Order Confirmation</h1>" & _
</head><body><p>Thanks for placing the order with us!" & _
</body></html>"
end if
'Add the standard header that is needed when sending new page from
' the server to the browser to the front of the response string
strResponse = "Content-Type: text/html" & vbCrLf & vbCrLf & strResponse
End Sub
The comments in this code segment provide a pretty good overview of what the code is doing. The code calls a user-defined procedure to return only the name field from all the string information that originated from the page. It makes a check to see if a name was supplied. If the name is missing, the code assigns to a string a series of HTML tags that make up the new pages. If the name is present, the order is stored in the database by calling a user-defined procedure. The page is built in a string with HTML tags thanking the user. Then the code adds a required header to the response string to indicate that HTML text format data is returned. The ProcessOrder method procedure then terminates, and the server returns the response string to the client. The client receives the new page, which came from an application-generated string rather than a file. Of course, the end user doesn't realize the difference; he just sees that a result page has arrived from his original query.
Consider the flow of this interaction when the user forgets to supply a name while specifying an order on the original Web page, as illustrated in Figure 19.1.
Figure 19.1 : Server validation of bad input.
The request went all the way to the server, which then detected the missing name, so no data was saved. The response page went back to the user. There's a little bit of overhead, considering that nothing was saved in the database. The interaction involved the user's time, network communication, and server processing time, all for the end result of no change to the server database.
Now you can finally see an alternative implementation where VBScript comes to the rescue! Suppose that you define exactly the same form, but you add a block of code to the page, as shown in Listing 19.3.
Listing 19.3. VBScript page-resident validation.
<script language="VBScript">
<!--
function frmOrder_OnSubmit
' Submit order if the request is valid
' Make sure user has supplied name before submitting order to server
if len(document.frmOrder.txtName.Value) = 0 then
' No name was supplied, order won't be submitted
MsgBox "You must supply a name.",vbOKOnly, "Can't submit order"
frmOrder_OnSubmit=false
else
' Order OK, submit it to server
document.frmOrder.submit
MsgBox "Order was submitted. Thanks.",vbOKOnly, "Confirmation"
frmOrder_OnSubmit=True
end if
end function
-->
</script>
The comments in this code once again provide pretty full details on what transpires. If the text box string has a length of 0, no submittal takes place. How is that accomplished? You simply set the return value of the ONSubmit event function to false. If you had no VBScript event handler, the browser would submit all data automatically. If you supply code for the OnSubmit event of a submit-type input button, the data is not submitted if you set the return value to false. You can see the handling of valid data in the Else branch of the conditional. If the name is present, the data is submitted by setting the return value to true. Once the form is submitted, the code executes the same process of launching the server application that was described earlier.
The advantages gained through validation are great. The code in Listing 19.3 has done something very significant: It has eliminated the need for any server-side validation. The Visual Basic code that stores data in the database no longer needs to check whether a name exists. It will only be called if valid data was first verified by the VBScript code that resides at the client computer. This saves processing time on the server when the data is saved. You use fewer lines for error-checking code. Better yet, consider what happens when an error does occur. Before, you had communication from the client to the server, processing on the server, and communication from the server to the client just to generate an error message to the user. Now, all that occurs is the client-side processing by the VBScript code. That generates the error message directly. All the network traffic, not to mention the user wait for the network and the server-side processing, is completely eliminated!
Figure 19.2 shows the flow for this interaction. Compare Figures 19.1 and 19.2, and observe the difference in approaches. This is a very simple, scaled-down example of the advantages of placing the validation load on VBScript rather than the server. Even this simple example shows significant savings.
Figure 19.2 : VBScript form validation flow.
As you can see, even though VBScript performs the processing on the client, it can have a close association with any programs on the server that might process data from the page. VBScript can execute front-end validation processing before form data is submitted to the server. It can screen out bad data or modify questionable data before submitting it to the server. The front-end processing reduces server load, network load, and even user wait time in the event that the data is bad and it must generate a reply. When this happens, VBScript can provide feedback right away without the server program generating a response and sending it back.
Of course, when you develop software in this manner, you must plan the scripts in conjunction with the server-side software. It does little good to have a script validate data if it's not validating it according to the right rules. Generally, this kind of in-sync planning of server application and script works out well because the server application must be planned in concert with the form anyway. VBScript can lead to a smoother performance from the entire server when you use it to perform the type of validation described here.
The previous example looked at eliminating overhead by avoiding the traffic in validating a page. Consider another kind of savings: What if you have a sequence of several pages the user must traverse in the process of collecting data? The traditional approach would be similar to Figure 19.3.
Figure 19.3 : A sequence of several pages with server interaction on each.
In this flow, each page leads to the other after it arrives at the server. The user must supply some data on each of three consecutive pages. The data for each page goes to the server, a server application saves the data to the database, and then the next page is generated and sent back to the user's client computer. This continues for each of the three pages. If the server finds errors during data validation, it must generate even more pages, and the flow shown in Figure 19.3 becomes even more complicated. To keep things simple, assume all data is okay for this discussion, but recognize that if there were data validation problems, the communications overhead would be even greater.
As you probably expected, VBScript provides a way to address this type of scenario and slice out the overhead, too. Figure 19.4 shows the flow you can achieve with VBScript.
VBScript dynamically controls the flow with this approach. This requires some special thought about which controls to use on a page. For this example, assume that the user must supply two fields on each page. You define a page with two text box input controls contained within a form, each preceded by a label. The form also has a submit input button. In addition, you add a label at the top of the page.
The first page is loaded with all label captions set relative to the first page. The caption on the submit button is assigned to read Next Page. The user supplies data in two fields and clicks the Next Page button. Script logic in the OnClick event for the button now controls the segue to the next page. The heading label and the labels by each text box are filled with new text to simulate page 2. A false value is returned to the OnSubmit event function so no real submittal occurs yet. The information that the user supplied in the two text boxes is tucked away into two script scope variables so that the script can easily retrieve it in a short while. A count variable is updated to indicate the user is now on page 2.
Now, the user interacts with page two. She might even have the perception that a new page was downloaded-after all, it looks different! She supplies two more pieces of information and clicks Next Page. Again, the OnClick event makes everything possible. From the count variable, it is clear to the script that page 2 is being processed. The heading label and the labels by the text boxes are updated with new captions appropriate to page 3. A false value is returned to the ONSubmit event function so no real submittal occurs yet. The caption on the button is now changed from Next Page to Submit because all the data will be complete after the next click. The count variable is incremented. Again, the text box values are retrieved and stored in different script-level variables.
Finally, the user completes the third page. She enters the final two fields of data and clicks Submit. At this point, the code in the OnSubmit handler can tell that this is the last page to process because the count variable is now 3. After validating the data, the script submits the form by returning a true OnSumit event return code and presents the user with a message box indicating this action.
The code must take one more action first before submitting the form. Did you notice it? After the user clicks Submit, the text boxes contain only two of the user's six responses. The rest are stored in variables, but input controls are the only easy way to communicate responses back to the server. No problem. You can use any format you want when supplying the form input fields. Use whatever convention the server-side application is expecting.
The VBScript code can do some data "massaging" or transforming to ensure that all the user's input takes the journey to the server. The VBScript code simply appends two of the variables onto each text field, separated by & for easy parsing. Each text field ends up containing the entries for three fields. Then the user selects Submit, and the data goes to the server. Listing 19.4 shows the code segment to handle this final page of the sequence.
Listing 19.4. Handling the final user input.
function frmOrder_OnSubmit
static intPageMode
' Check to see what simulated page is being processed
if intPageMode = 0
'. . . code here to handle cases of other page modes
frmOrder_OnSubmit=false
elseif intPageMode = 3 then
' Last page, submit the data
' Consolidate data from prior pages so it all travels with form fields
document.frmOrder.txtField1 = document.frmOrder.txtField1 & _
"&" & varA & "&" varB
document.frmOrder.txtField2 = document.frmOrder.txtField2 & _
"&" & varC & "&" varD
' Submit the data to the server and tell user
frmOrder_OnSubmit=true
MsgBox "Your order has been submitted, thanks!", _
vbOKOnly, "Confirmation"
end if
end sub
This example illustrates a very powerful concept. An interaction that would usually require several pages and involve considerable network time is reduced to just a single page. Instead of sending data to a server application three times in the process of making the order and causing three different database changes, the script makes only one submittal after the user has supplied all the data. The user's waiting time is drastically reduced. For any validation problems, feedback to the user is immediate. It's a complete and total victory over the old approach.
Well, almost total. The VBScript approach has a couple slight disadvantages, too. This approach does require additional script coding. The coding is not always really clean or clear if you're handling a large number of fields. Page aesthetics might suffer to some degree. It will be harder to dynamically simulate three drastically different pages unless they are generic in appearance.
Still, these disadvantages are minor compared to the advantages of the overhead and time saved. Good planning and design can make this kind of script approach easy to put in place. You can use many tools to help make a single page take on a changing character. You can use labels to change captions. Text boxes can change multiple lines of displayed text. You can use the New control covered on Day 11, "More ActiveX Controls," to hide or show images by changing display dates. Button captions can be modified between simulated pages. You can change the color of a label from one simulated page to another to highlight differences between pages. Message box and input box functions can provide a high level of user interaction. By taking this approach, you are really moving the page more in the direction of an application and further from the original Web page model of a static piece of text. The end result is good for the user. Better interactions and better responses are the net gain from using VBScript to simulate a series of pages. It won't work out in every case, but keep your eyes open for situations where you can apply this. When it does present itself as an opportunity, you can take advantage of it.
Today's lesson looks at server-related VBScript issues. Although VBScript performs processing on the client, it has a close association with any programs on the server that might process data from the page. VBScript can carry out front-end validation processing before form data is submitted to the server. This saves on server load and also eliminates unnecessary network load and user wait time in the event that the data is bad and not ready to be stored. In that case, the user-level notification can occur immediately from the client-based VBScript, rather than wait on the server to detect the problem and provide a response.
It is important to keep the role of VBScript clear when considering NT Server solutions because Visual Basic can be involved in several areas of the solution. VBScript is supported in the Internet Explorer and other browsers to provide client-side solutions. You can also use VBScript with Internet Information Server to serve as a scripting language for various server-side tasks, although that is not the focus of this book. In addition, you can use Visual Basic to generate OLE Automation Server DLLs residing on the server that can be called in response to form input on a page. The mechanism for calling such programs is using ISAPI to call the oleisapi DLL on the server. oleisapi is specified as the form action parameter on the page itself. Other server technologies include IDC, which makes generating server data from a database very easy, and the standard CGI, or Common Gateway Interface. CGI programs that are triggered on the server from a page are commonly called scripts. Future versions of Visual Basic will support using that language to produce ActiveX controls. Then, you can distribute Visual Basic-produced controls. With the multiple layers of Visual Basic in various Internet solutions and the use of script at several levels, there is quite often confusion among people who are not well versed in these technologies. Now, you can lead the way in shedding light on this confusion!
Today's lesson concludes by examining strategies to reduce the number of pages downloaded from the server by replacing several static pages with one dynamic page. The controls and techniques that greatly facilitate this include the label control, the text box, the message box function, and the input box function. In addition to these controls and techniques, careful thought is required to plot out the optimal strategy for the right mix of function, scripting, and downloaded pages.
| Q | Does VBScript enable you to have any interaction with the input buttons of the submit type? |
| A | Yes, you can have code in an OnSubmit event for the form. You can use this code to perform field validation and control whether the code is submitted. |
| Q | What are the advantages of using VBScript in your Web page to validate data, rather than relying on the server to do it? |
| A | When your script validates data before submitting it to the server, you avoid all the overhead of unnecessary network communication if the data turns out to be invalid. In addition, you spare the server from doing the validation work, thus lightening the load on its CPU. This can be an important consideration, especially when the server tends to be overloaded anyway. |
| Q | Name two user interface techniques that you can use to provide dynamic page feedback. These techniques enable you to use only one changing page for a user interface rather than multiple pages. |
| A | The possibilities include using labels or text boxes for feedback, as well as feedback and interaction through input boxes and message boxes. |
Explore many Web pages on the Web. See if you can find page sequences where a flow of several pages could be reduced to one page if the pages were more active and dynamic.
| Note |
Refer to Appendix C, "Answers to Quiz Questions," for the answers to these questions. |