home / articles / frontpage

Form Handlers With FrontPage 98

Last week I began this series by talking about designing forms with FrontPage 98. I walked through  the form fields most commonly used, and demonstrated how each one can be customized. This week, I will talk about Form Handlers, and next week, I'll be discussing and demonstrating Form Validation.

Part 2: Form Handlers

A form is designed to send data somewhere. I would have said that it is designed to collect data and send it somewhere, but actually, there are many forms which don't collect data, but already have data in them. And, in fact, there are some forms which aren't designed to send data somewhere either, but are used in scripting to handle the data within the page. But 99% of forms do send it somewhere. And where that data is sent is a function of the "Form Handler." This is a naming convention for the "Action" property of the form. And what is that? Let me explain:

A typical form tag has at least the following attributes (or "properties," they are the same thing), as illustrated in the following form tag:

<form method="POST" action="FormHandlerName">

You shouldn't have to worry about the "method," as this is almost always "POST." In addition, a form can have a number of other properties, such as "name," "onSubmit," etc., depending on how you wish to use it.

Think of the data in the form as a baseball, and the form is the pitcher. The Form Handler is the catcher. It "handles" the data in any number of ways. Data from a form can be used by a CGI program, written to a file, inserted into a database, displayed in the following page, or used by an ASP page to influence the behavior of its' scripting. FrontPage has some built-in form handlers, called "components" or "WebBots," that can perform a variety of functions as well. Let's start by discussing them.

Discussion Groups

FrontPage has a "Discussion Web Wizard" which you can use to either create a new Discussion web, or add one to an existing web. This is done by going into FrontPage Explorer and selecting File|New|Discussion Web Wizard from the menu. By following the instructions in the Wizard, you create a set of pages, most of which contain forms that are used to enter messages in these discussion groups. The form handler in this case is the "Discussion" WebBot. It takes the contents of the form and adds them to an HTML page that is used to display the various messages. Once these pages are created, you can customize them in any way you wish. However, be careful about reorganizing the structure of the web itself. I am not personally fond of the FrontPage Discussion Web, as it is very difficult to maintain. To remove messages, for example, requires editing a number of related pages, and if you make one mistake, your discussion web doesn't work properly.

User Registration

The User Registration Form is used when you want to require users to register in order to have access to your web. This involves "permissions." By default, everyone has "browse" permission to a web site. To use the Registration component, you must first set permissions in Frontpage Explorer. This is done by selecting Tools|Permissions... from the menu. In the "Settings" Tab, you must first set the web to have its' own unique permissions (by default, child webs inherit permissions from the root). Then click "Apply" and go to the "Users" tab. Check the box which reads "Only Registered Users have browse access."

Now you create your form for User Registration. The form must reside in the Root Web (of course, as the Users must register before they can get into the child web!). Create your form, with text fields named "Username" and "Password" (actually, you can name them anything you want, as long as these names correspond to the ones in the dialog box I am about to discuss). Right-click the form, and Select "Form Properties" from the popup menu. Click the "Send to Other" radio button, and select "Registration Form Handler" from the drop-down menu. Then click the "Options" button and customize the form. The most important item in this dialog box is the "Web Name" field, in which you specify what web this form handles. Just type in the name of the child web for which you want to restrict access. There are 4 tabs which you can use to customize the way the form is handled. Most of the settings will be set by default, but you may wish to change some of them, such as the "Failure" page, the "Confirmation Page" (the page to which the user is sent after submitting the form), and the "Form Results" page (the page which gathers the information from this one). In addition, you may want to gather additional information from the user. You can do this by adding form fields to the page, and also by using the "Saved Fields" tab of the dialog box. This sepcifies which fields of the form you wish to save information from, and gives you the option of gathering additional information about the user, such as his browser type, computer name, etc.

The drawback to this is that anyone who registers has access to the web you set this up on. It isn't the most secure way of restricting access, but does allow you to gather information about those who visit your web site.

E-mail Results

This option is only available in FrontPage 98. I would guess that this was added due to the extremely large number of people who wish to have form results emailed to them, rather than having to open a page in their web to get the form information. It is a welcome addition. However, the options for this are rather limited, and you may wish to purchase a CGI program for handling your forms by email.

To use the "E-mail Results" component, create your form, right-click it, selct "form Properties" from the popup menu, and type in the email address you want the results to go to. Then click the "Options" button to customize the behavior of the component. Here again, you have 4 tabs in which you can customize how the results are handled, and they are similar to the Registration dialog box in most ways. The biggest difference is in how you wish to format the email itself. There are a large number of formats to choose from, including formatted text, HTML, and comma-delimited database format (in case you wish to import the results into a local database).

Save Results

This is the simplest form of component. It saves the form results to a file in your web, usually in your _private folder, where only you can see it. You have several options as to how the results are saved, all of them similar to the ones I've described above. Use the"Options" button of the "Form Properties" dialog box to customize this component.

Other Form Handlers

In addition to using FrontPage Components, there are a number of other ways of "handling" form data. I will discuss the most popular ones.

CGI Programs

A CGI (Common Gateway Interface) program is either a script or an executable file that runs on the server. CGI programs can do virtually anything, as long as the hosting service approves of what they do. Some hosting services won't allow you to use them at all, for this very reason. CGI programs are typically used for a variety of purposes, such as email, database-connectivity, and custom-generating results pages according to the data that is posted to them. The one thing they all have in common is that they return the user to a results page of some kind.

IDC Scripts

IDC (Internet Database Connector) is a technology that Microsoft developed for making database connectivity relatively simple to the web developer. In FrontPage, there are some wizards for implementing these scripts and the resulting "HTX" pages (formatted data display or results). For more information on using IDC, see my earlier article and see my web site at http://www.connectrans.com/takempis. IDC is a function of IIS (Internet Information Server), and is only available on NT platforms.

ASP (Active Server Pages)

ASP is a technology that Microsoft developed for dynamically generating pages using server-side scripting. An ASP page is capable of reading form data submitted to it, and dealing with it in an almost unlimited variety of ways. In fact, because of ASP's ability to interact with COM objects (Common Object Model), if you're a programmer, you can create your own COM objects on the server(assuming that your ISP will let you), and perform virtually any server-side task with it. This makes ASP as powerful as CGI. Of course, there are a good number of COM objects built into the IIS platform, which you can use simply by writing your server-side scripts on the page. The Complete Webmaster has a section for ASP, if you want to learn more. In addition, my web site has a number of tutorials dealing specifically with using ADO (ActiveX Data Objects) to interact with databases on the server.

That's about it for form handlers. I haven't discussed some of the more esoteric uses of forms, but I feel like I've given you a good bit to chew on, and covered the most common uses of them. Next week I will be discussing Form Validation, which can be critical in many instances. So stay tuned!

Author: Kevin Spencer
Date: 01/30/98

More articles about Microsoft FrontPage
More articles by Kevin Spencer
Author Biography