Chapter 19

Dynamic Page Flow and Server Submittal

CONTENTS

• The Advantage of Validating Server-Bound Data
• Reducing Traffic by Scripting Dynamic Pages
• Summary
• Q&A
• Workshop
• Quiz

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 guide 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.

The Advantage of Validating Server-Bound Data

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 guide, 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.

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 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.

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.

Reducing Traffic by Scripting Dynamic Pages

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.

Figure 19.4 : A sequence of one page due to VBScript validation and flow control on the original page.

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.

Summary

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 guide. 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&A

Workshop

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.

Quiz

1. The following code is intended to perform a validation check that confirms that a user is 18 or over before processing a job application. If the user age is 18 or over, then the form input should be submitted to the server. The current code has an omitted statement that prevents the submission from taking place. Add the missing statement so the submittal occurs when data is valid:
   <HTML>
   <HEAD>
   <script language="VBScript">
   <!--
   function frmApply_OnSubmit
   ' Process the application by submitting to server if data is valid
   
      ' Make sure the user age is 18 or over
      if document.frmApply.txtAge.value < 18 then
          MsgBox "Sorry youngster, you're not old enough to apply!", _
              vbOKOnly,"Can't take app"
   frmApply_OnSubmit=False
      else
          MsgBox "Application processed", vbOKOnly, "Confirmation"
      end if
   end function
   -->
   </script>
   
   <HR>
   </HEAD>
   
   <BODY LEFTMARGIN=10 TOPMARGIN=20 TEXT=#000000
    LINK=#FF0066 VLINK=#330099 ALINK=#000000>
   <FONT FACE="ARIAL" SIZE=2>
   <CENTER>
   <em>Enter your information:</em>
   <BR>
   
   <!------ Job Application Form ------------------->
   <form name="frmApply" action="/scripts/oleisapi.dll/HumanRes.JobApp.TakeApp"
         method="GET">
   Name: <input name="txtName">
   Address: <input name="txtAddress" >
   Age: <input name="txtAge">
   Job Desired: <input name="txtJob">
   <input  value="Apply" name="cmdApply"type="submit">
   </form>
   
   </BODY>
   </HTML>
2. Modify the correct code from Question 1 so that it only submits the form if the user is over 18 and supplies a name.