Dynamic Page Flow and Server
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
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
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.
You can also use VBScript on NT Server with the Internet Information Server Web server software. The focus of this guide 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.
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">
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,
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
(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.
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
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.
a page scolding the user
= <html><head><h1>The name is missing!</h1>"
supply a valid name with the order!" & _
' Store order
info from page in database
a page confirming to the user
= <html><head><h1>Order Confirmation</h1>"
for placing the order with us!" & _
'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
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
Listing 19.3. VBScript page-resident validation.
' Submit order if the request is
' Make sure user has supplied name before
submitting order to server
= 0 then
' No name
was supplied, order won't be submitted
MsgBox "You must
supply a name.",vbOKOnly, "Can't submit order"
OK, submit it to server
was submitted. Thanks.",vbOKOnly, "Confirmation"
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
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.
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
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
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.
' Check to see what simulated page is being
if intPageMode = 0
'. . . code here to handle
cases of other page modes
elseif intPageMode = 3 then
' Last page, submit the data
data from prior pages so it all travels with form fields
= document.frmOrder.txtField1 & _
& varA & "&" varB
= document.frmOrder.txtField2 & _
& varC & "&" varD
Submit the data to the server and tell user
"Your order has been submitted, thanks!", _
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 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||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.
Refer to Appendix C, "Answers to Quiz Questions," for the answers to these questions.
- 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:
' Process the application by submitting to server if data
' 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!", _
processed", vbOKOnly, "Confirmation"
<BODY LEFTMARGIN=10 TOPMARGIN=20 TEXT=#000000
LINK=#FF0066 VLINK=#330099 ALINK=#000000>
<FONT FACE="ARIAL" SIZE=2>
<em>Enter your information:</em>
<!------ Job Application Form ------------------->
<form name="frmApply" action="/scripts/oleisapi.dll/HumanRes.JobApp.TakeApp"
Name: <input name="txtName">
Address: <input name="txtAddress" >
Age: <input name="txtAge">
Job Desired: <input name="txtJob">
<input value="Apply" name="cmdApply"type="submit">
- Modify the correct code from Question 1 so that it only submits
the form if the user is over 18 and supplies a name.