Creating FORMs

The HTML <FORM> Tag is the starting point for virtually any interactive Web Page. Unfortunately, HTML has demonstrated a number of shortcomings in this area, especially in regard to the background or inter-page processing tasks which, until now, forced you to deal with Scripting Languages.

As we'll see in a moment, heitml provides special tools that address this problem. To illustrate this, we begin with a conventionally coded HTML form. Our purpose will be to examine the form from a new perspective, and see how the ability to define new Tags not only simplifies the design process, but handles the background processing chores as well.

Suppose, for instance, that we wanted to create the following simple input form:

Guest book form: Guest_Name Email Address Country Comment

Here's an example of how HTML users might create this form:

Filename: form.hei

<FORM action="javascript:void(0)"> <table border="border"> <caption > <b>Guest book form:</b> </caption> <tr > <td >Guest_Name </td> <td > <input name="Guest_Name" size=25> </td> </tr> <tr > <td > Email </td> <td > <input name="Email" size=25> </td> </tr> <tr > <td > Address </td> <td > <input name="Address" size=25> </td> </tr> <tr > <td > Country </td> <td > <input name="Country" size=25> </td> </tr> <tr > <td > Comment </td> <td > <textarea name="Guest_Comment" cols=25 rows=2 wrap="physical"> </textarea> </td> </tr> </table> <input type="button" value="Enter"> </FORM>

FORMs Processing

Now that we've created a simple form, the question still remains of what to do with the data once the form has been filled out by a User.

Those who already have experience with Scripting Languages know that the usual purpose of the Submit button is to pass control of the newly entered data to a CGI Script. This script file is named in the action parameter of the <FORM action> Tag. But notice that in our own example, instead of calling a CGI Script, we called another file with an .hei extension:

<FORM action="formproc.hei">

The reason for this is that heitml is quite capable of handling it's own processing chores, even when they involve operations like retrieval or update of data in SQL Databases or sending emails.

But now it's time to see how it would work in a real-world application. Since our work thus far has been to design an input form for a Guestbook database, we may as well take a look at the code that would be required to take this data and add it to the Guestbook:

Filename: formproc.hei
<dbupdate> insert into guestbook (Guest_Name, Email, Address, Country, Guest_Comment) values (<? ff.Guest_Name "Q">, <? ff.Email "Q">, <? ff.Address "Q">, <? ff.Country "Q">, <? ff.Guest_Comment "Q"> ) </dbupdate> Your record has been entered in the Guestbook. Click <a href=homepage.hei>here</a> to return to our Home Page.

In keeping with our usual conventions, the heitml-specific code is high-lighted in blue, and the rest (the SQL INSERT command and the HTML Tags and text) appears in black.

The HTML <FORM> Tag took each of the input fields named in the form from the previous page, along with the data that had been entered, and passed it on to the file formproc.hei for processing. The ff. prepended to each variable name is heitml's way of re-gaining access to this "form field" information. The ? Tag then writes the data into the appropriate place within the SQL INSERT command in "Q" (quoted) format.

Once the update has been performed, a message appears in the User's Browser window and (s)he is given the opportunity to return to a particular page on the Web Site.

FORMs Checking

Until now, we have just demonstrated how heitml can be used to create a form processing script that has functionality similar to a CGI Script. But heitml's capabilities go even further.

Just imagine, someone would submit an empty form. The processing script (in this case formproc.hei) would put the empty fields in the database. You will agree that such a Guestbook entry is really useless. You have two alternatives now: Deleting useless Guestbook entries from the database on a regular basis or avoiding useless Guestbook entries to be put in the database. You will find, that the latter alternative causes less work on the long run, so you decide to update the processing script to the check the form fields before they are put in the database. You might update formproc.hei to something like that:

Filename: formproc.hei

<if !isempty(ff.Guest_Name) && !isempty(ff.Email)> <dbupdate> insert into guestbook (Guest_Name, Email, Address, Country, Guest_Comment) values (<? ff.Guest_Name "Q">, <? ff.Email "Q">, <? ff.Address "Q">, <? ff.Country "Q">, <? ff.Guest_Comment "Q"> ) </dbupdate> Your record has been entered in the Guestbook. Click <a href=homepage.hei>here</a> to return to our Home Page. <else> Your record has not been entered in the Guestbook, since you have to specify a Guest_Name and Email address. Click <a href="form.hei?<? ff "Un">">here</a> to redisplay the form. </if>

Your processing script has become more robust now. A Guestbook entry is only inserted in the database, if a Guest_Name and an Email has been entered by the user. We used the if Tag and the isempty() function to check whether the fields are empty and to emit an appropriate message. For example, if a user has submitted an empty form, our new processing script will tell him what (s)he forgot to enter and the user will click on the link that will redisplay the form.

Redisplaying FORMs

Now imagine, the user has entered some kilobytes of text in the Comment field but forgot to enter the Guest_Name and/or the Email address. When clicking the link redisplaying the form, (s)he might wonder where his comment has gone. Disappointed from this stupid Guestbook application (s)he will leave your Web site and may never come back.

The reason for this is that our form.hei cannot remember the field contents the user entered before. To overcome the problem, the form fields have to be passed back to the form and the form must be able to restore the form fields.

Passing back the form fields is already provided in our processing script, by appending them as URL parameters to the URL that will redisplay the form:

<a href="form.hei?<? ff "Un">">here</a>

The ? Tag will format each form field in the ff object as an URL parameter (format "U") prefixed with its name and the = sign (format "n").

To restore the fields in the form, each <input> field or <textarea> must lookup its value in the ff object. Since we have four text fields here, we apply what we have learned in Modular Pages and redefine the HTML <input> and <textarea> tags so that they do the lookup procedure, put the redefinitions in a file and include the file in form.hei. This leaves our original form.hei nearly unchanged.

Filename: myformfields.hei

<def input name size value=null; // Lookup field value value=default(ff[name],value)> // Generate HTML input tag <\input <? name "Pn"> <? size "Pn"> <? value "Pn">> </def> <defenv textarea name cols rows wrap; // Lookup field value assign value;defbody;/assign; value=default(ff[name],value)> // Generate HTML textarea tag <\textarea <? name "Pn"> <? cols "Pn"> <? rows "Pn"> <? wrap "Pn">> <? value "Pn"> <\/textarea> </defenv>

Our redefinition of the HTML <input> tag, uses the default() function to specify a value for the field in case ff is not defined. Then, the default value is the value of the value parameter. In the case that ff is defined, the expression ff[name] gives us the value of the form field with name name. As we already know from the redefinition of the HTML <BODY> tag in the section Modular Pages, we use the backslash character to use the <input> tag as it was originally defined by HTML. Furthermore, the parameters of the <input> tag are generated by printing the parameters name, size and value of the redefined tag using the "Pn" format of the ? Tag. The "Pn" format formats the argument of the ? Tag for use inside an HTML tag (format "P") prefixed with the name of the argument and the = sign (format "n").

The redefinition of the HTML <textarea> tag works similar, except that the default value for the form field is the text between the <textarea> and </textarea> tag referred to as defbody.

Here is what our new form.hei looks like:

Filename: form.hei

<include name="myformfields.hei"/> <FORM action="javascript:void(0)"> <table border="border"> <caption > <b>Guest book form:</b> </caption> <tr > <td >Guest_Name </td> <td > <input name="Guest_Name" size=25> </td> </tr> <tr > <td > Email </td> <td > <input name="Email" size=25> </td> </tr> <tr > <td > Address </td> <td > <input name="Address" size=25> </td> </tr> <tr > <td > Country </td> <td > <input name="Country" size=25> </td> </tr> <tr > <td > Comment </td> <td > <textarea name="Guest_Comment" cols=25 rows=2 wrap="physical"> </textarea> </td> </tr> </table> <input type="button" value="Enter"> </FORM>

We have created now a form and a processing script using heitml that are more intelligent than an ordinary HTML form and its CGI processing script. Our processing script avoids useless Guestbook entries to be put in the database while giving the user the chance to enter missing fields and keeping the field values (s)he entered before.

Our example could be enhanced much further. For example, we could build one heitml page that is form and processing script at the same time. This would reduce maintenance efforts and makes it possible to redisplay the form immediately without clicking a link. We leave these enhancements to you as an exercise.

Now, that you understand the concepts of programming forms with heitml, you can start building your own real-world application using the heitml Application Components for forms and fields. These tools incorporate all what you have learned so far about forms and form processing scripts.

Wizards

A wizard is a sequence of FORMs and a processing script, that are used to install, configure or generate a program, data or even hardware devices. The FORMs of a wizard are connected to each other by back and forward (next) links which the user can navigate in any order. On the last FORM, there is something like a submit button which triggers the processing script. While navigating through the FORMs, the user settings must be kept somehow over several page requests until the submit button on the last FORM has been pressed and the settings have been processed.

This shows us that interaction is not just a simple one-way process where a user inputs data into a form, submits the form to pass the form data to a processing script, but it is an iteration through all these stages. This iterative process is called a session.

Using heitml's Session Mode, we could keep track of what has been entered so far, even over multiple page requests. With heitml sessions, programming wizards becomes very easy.

Summary

Building interactive pages requires the use of FORMs and form processing scripts.

Ordinary HTML FORMs and CGI scripts lack the capability in checking FORMs and keeping track of what has been entered into the FORMs so far.

By programming a Guestbook application and presenting the concept of wizards, we found out that creating interactive pages is not just writing an HTML <FORM> tag together with a lot of HTML <input> fields and <textarea>s and attaching a generic PERL script that just puts the form fields into a database or an email. Interaction is an iterative process incorporating the user, the form and the processing script as the stages.

For this purpose, heitml provides a Session Mode to keep track of what has been entered into the FORMs, a lot of Application Components for forms, fields and several other components to help you develop intelligent interactive pages like Search Engines, Mail Forms or Database Management Applications.