SE USING CGI

Add To MyInformIT

< Back Contents Next >

Author: Michael Erwin
Retail Price: $59.99
Publisher: Que
ISBN: 0789707403
Publication Date: 4/19/96
Pages: 1000

Chapter 5 - Using HTML and CGI as a User Interface

If you're reading this book, you may already know the basics of writing HTML documents. This ability has allowed you to create a wonderful home page, or even maybe a basic corporate Web site, with pretty images.

Because you already know (or should know) the basics of HTML, this chapter doesn't rehash the basics. For that information, you can find plenty of good books, such as Special Edition Using HTML, published by Que Corporation. When you began to learn more about HTML and the Web, you probably noticed that at some sites you could actually put information directly into some HTML pages. In fact, I bet that's the reason most of you bought this book-you wanted to do some of these cool things in your Web pages.

In this chapter, you take an in-depth look at what HTML tags you need to know about so that you can begin creating and using CGI scripts. You also learn how to tie HTML documents to sample CGI scripts and how to link HTML documents to real-world CGI scripts. As you work with these HTML tags, you'll examine real-world examples of how to create interfaces to your CGI applications.

By properly using HTML as the middleware for the user interface for CGI scripts, you'll increase the overall usefulness of your CGI application, which in turn will increase the traffic to your site. And if your hit counts start to grow rapidly, you'll know that your CGI applications are being effective.

In this chapter, you learn how you can use HTML and CGI to present your application to the end user. During this process, you'll make the use of the CGI application as easy as possible to the client. This chapter also shows you some examples of good, bad, and ugly HTML and CGI scripts. More specifically, this chapter will show you how to

Integrating CGI into Your HTML Pages

One of the easiest ways to learn to do something is by seeing an example. In this section, you learn how to integrate the CGI application into the example HTML form pages by using a simple, real-world scenario.

Suppose that you're the Webmaster for a stock-trading firm. For the past year or so, the company has maintained a Web site that promotes its offerings to individual investors in the way of saving them money and helping them handle their stock portfolio.

Because of your hard work, the Web site has done very well for the firm and has started to land some great clients. Because it has done well, management has decided that, as an additional incentive to help land prospective clients, the company should give out time-delayed stock price quotes over the Web. The company already offers these quotes if someone calls the company for them, and with so many business executives having access to the Web, this idea seems like a great way to reach the market.

You already have all the stock price data in your computer systems, and it's being updated in real time. The people in your information technology department have told you that they'll write a CGI program to access the stock information to your specification. Well, they just took the hard part, so that part of the equation is done. The next part is properly handling the HTML user interface to the CGI script.

At this point, you, the Webmaster, come in. You've been given the task of creating the HTML front end for this CGI application. Don't take this part of the project lightly. If users can't figure out how to use the CGI application, or if it's overly complicated, they won't return to use it. And if users don't return to use it, they won't end up as clients for your company, and you'll be looking for other gainful employment. So spend some time on creating the HTML interface.

When you're creating an HTML user interface for CGI, start by writing down the information users will need to send to the CGI application through HTML. This task ties into defining what the CGI is supposed to do. In this example, what information do you need to know from the users? Start simple for now. All you need to know from the users is the stock symbol they want a quote for.

The <FORM> Tag

Now you're ready to start the HTML interface. You want an interface that will look something like figure 5.1 when you're finished. The first thing you need to learn about is the HTML <FORM> tag. This tag is slightly more complicated than it appears to be at first glance. When a browser comes across this tag inside your HTML document, it knows that a form is being constructed.

Figure 5.1 : Your goal is to create this HTML interface for the example Stock Quote Service.

You already know how to start the basic HTML document. Listing 5.1 shows the top part of an example HTML page. Nothing complicated so far.

When a browser reads this code, it will create a nice, simple beginning to your HTML interface, as shown in figure 5.2.

Figure 5.2 : The code in listing 5.1 results in this HTML page.

The next line in your HTML code is as follows:

This line actually is the start of the HTML interface. As you can see, this line of code has several elements to it. The first item, FORM, tells the browser that a form started, and that's all this HTML code line really does.

The real power of this tag lies in the attributes and subsequent tags that you can use with it. The FORM tag has two attributes that must be defined: METHOD and ACTION.

The METHOD Attribute

The METHOD part of the <FORM> tag tells the browser how to send the information back to the server. METHOD has only two possible values: GET and POST. The difference between these different methods is how the browser encodes the data to be sent back to the CGI server.

With the GET method, the information is appended to the URL through the query string and then assigned to the environment variable QUERY_STRING on the server. The GET method encodes and sends both the variable names and values for those variables with the URL. The downside to using GET is that you're limited to a total of 255 characters, including the URL encoding overhead. If you're sending information from a complicated form, GET doesn't provide enough resources for you. In this case, however, because you're asking only for the stock symbol, the GET method shouldn't be any problem.

On the other hand, the POST method sends the information to the Web server by using standard input (STDIN). With this method, the browser doesn't append variables to the URL like the GET method does. Instead, the POST method connects to the Web server, and then the browser sends each value from the HTML form to the Web server. As you learned in Chapter 3 "Designing CGI Applications," the Web server then starts the CGI application and passes the user-supplied data to the application.

Which METHOD you use depends on the CGI application. All Web servers support the GET method, and most simple CGI applications use the GET method. Because the POST method has no character-length limitations, POST is the only option you have for encoding data from a complex from, and most modern Web servers support the POST method. Most often, I prefer using POST to send form data to CGI applications.

The ACTION Attribute

The last part of the <FORM> tag, ACTION = "/cgi-bin/quote.pl", is the ACTION attribute. ACTION tells the browser what the URL of the CGI program is so that the browser knows where to send the encoded form information. In this case, the browser is going to send the form information to a Perl CGI program called quote.pl on the same server as the HTML document. So if the rendered HTML document comes from a server named www.mcp.com, the browser will send the encoded information to the quote.pl program on the server www.mcp.com. You can also see where that program is located on the server; it's in a directory called /cgi-bin/. This means that you could send FORM data to someone else's CGI application and, depending on their CGI script, the data would be processed and information returned to the user. Many individuals lacking scruples do this with Web search engines and page-hit counters.

You also can include the complete URL within the ACTION attribute as follows:

Which way you handle the ACTION attribute really doesn't matter, as long as a valid URL appears within the ACTION attribute of the <FORM> tag.

The </FORM> Tag

Like with many HTML tags, you need to place a closing </FORM> tag at the end of the form. This doesn't have to be the end of the HTML document.

You can have multiple forms within the same HTML document. When you end one form with the </FORM> tag, you can then create another form by using another opening form tag, <FORM ACTION="/cgi-bin/scriptname">. If you use multiple forms in the same HTML document, the defined CGI script, referenced by the ACTION tag, should be different for each form.

Inputting Data

Now that you know how to start the <FORM> part of your HTML project, you need to decide how you want users to input their information into the form. You do this using an <INPUT> tag, as follows:

This example is a simple <INPUT> tag. All it does is tell the browser to get ready for some sort of data input.

The TYPE Attribute

The TYPE attribute tells the browser what kind of data will be input and how it should look on the form. This attribute of the <INPUT> tag controls what the rest of the attribute of the completed tag will be.

In the preceding example, the browser is told that it will be a standard text variable. You can use several options with the TYPE attribute. The default value for TYPE is text, or TYPE="text".

You can use eight different TYPE variables: text, password, hidden, checkbox, radio, image, submit, and reset. The first one, TYPE="text", not only tells the browser to expect to receive text input, but also tells the browser to start building a text field on-screen, so users can send text data in a field named symbol1 (NAME="symbol1").

Now when you decide to use TYPE="text", you've automatically made another decision regarding the rest of the <INPUT> tag. That the NAME attribute has to be used is a given. The remaining attributes of the <INPUT> tag change according to the TYPE of data to be input.

The text formatted field has two close TYPE cousins: password and hidden, as discussed in the following sections. The other types available-checkbox, radio, submit, and reset-are discussed later, under the section "The VALUE Attribute."

The password Type. The main difference between TYPE="password" and TYPE="text" is that when you use password, anything users type into the field is displayed as asterisks. The password type is good for hiding sensitive information from prying eyes as your form is being filled out.

The hidden Type. By using hidden fields, you can hide the field values from users. You're probably asking yourself, "Why would I want to do that?" Hiding values allows your CGI applications-especially games-to pass back to your browser hidden information within an HTML form. This way, the CGI application doesn't have to remember everything that everyone in the entire world is doing. To see how these differences in <INPUT> HTML code will be rendered with Netscape's Navigator browser, look at the text field examples in figure 5.3.

Figure 5.3 : You can set up the text type in five different ways.

Consider this example: You create a Web-based adventure game that's designed to allow many people to play at the same time. When a player makes a move or picks up an item, the CGI game can retain this data, along with other information, and send it back to the player's browser via HTML. Without too much trouble, the CGI game can determine what each game player is carrying, how many moves each player has left, each player's score, and the location of each player by keeping track and updating hidden fields.

Although I'm using a Web-based CGI game as an example, we all know that the really hidden power of computers is for business applications, right?

The NAME Attribute

The NAME attribute of the <INPUT> tag tells the browser what the name of the inputted data variable is going to be. You must have a NAME attribute in each <INPUT> tag. In this example, the NAME of the text data is going to be symbol1. (You'll be using the NAME attribute with other tags later in this chapter.)

The SIZE and MAXLENGTH Attributes

In the running example, <INPUT TYPE="text" NAME="symbol1">, users can type as much into the text field symbol1 as they want. You don't want to allow that, however, because someone somewhere might type a bunch of junk into this field. And because the CGI programmers in the IT department just told you that their CGI script can handle only five characters, you need to display an input field that's only five characters long. To do this, you can use the SIZE attribute to define the length of the field users will see on the form:

This line tells the browser to limit the users' input form area to five characters.

The SIZE attribute determines how big the field will be drawn on the form but doesn't limit the amount of text that can be typed into the field. To set this limit, use the MAXLENGTH attribute.

The VALUE Attribute

The VALUE attribute allows you to assign a default value for a field. So if you write some HTML code like this,

the initial value of the text variable country would be USA. But this would only be the default value, because the users can change this field.

As you learn soon, you can use this attribute with most types of <INPUT> tags. If you want to create a field with a default value you don't want users to change, consider using it with the HIDDEN attribute.

The checkbox Type.

Check boxes are a little strange when it comes to the VALUE attribute, but it works like this: If the user selects the check box, the variable indicated by the NAME attribute will equal the VALUE attribute. If the check box isn't selected, the variable will contain nothing (null string). In the preceding example, if the check box is selected, the variable info1 will be set to 1. If it's unselected, the variable info1 will be empty.

The radio Type. Radio buttons allow you to create an interface element for users to select only one option from many. The following HTML code shows how to create a radio button input for a variable called morf:

When the browser renders these <INPUT> tags, it will create two round radio buttons. In this example, Male is selected by default because it has the word CHECKED following the VALUE attribute. If a user clicks the button next to Female, the radio button next to the word Male is deselected, and the radio button next to Female becomes selected.

Notice that these two <INPUT> tags have the same variable NAME of "morf". For radio buttons to work together, you must assign the same variable name to them. To have different sets of radio buttons on the same form that work independently, be sure to assign a different variable name to them.

The submit and reset Types. After you finish the HTML form's interface, you need to add a submit button so that users can send the input data to the CGI application. While you're at it, you should also be considerate and add the reset button, so users can clear the form and start over, if necessary. You can make all these changes by using two lines of HTML code:

The HTML line that contains the <INPUT> tag with the TYPE of reset causes a user's browser to create a button labeled Reset. If the user clicks this button, the browser resets, or sets the content of the HTML form to its default state (usually empty, or to its default values as defined by the element's VALUE attribute).

The submit type is absolutely necessary to use forms. An <INPUT> tag with TYPE="submit" and VALUE="Send" causes the browser to create a button labeled Send. Users can click the button to cause the browser to send the data entered into the form to the server.

The ACTION attribute in the opening <FORM> tag determines the program the server will pass the form data to. Neither type attribute (reset nor submit) requires you to use the NAME attribute with them. If you don't use the NAME attribute with them, the browser will automatically label the buttons Reset and Submit.

Finishing the HTML Interface

Now you're ready to finish your company's form for Web-based stock quotes. SEC laws dealing with the stock market require that you not give more than five stock quotes at a time via electronic means, so you need to take this factor into account. And you already know that none of the stock ticker names are longer than five characters.

As you learned earlier, the programmers in your firm's IT department will write the Perl CGI script, named quote.pl. So all you need to do is to finish the input HTML document for this project. Listing 5.2 shows the last part of the actual HTML interface for the CGI stock-quote application.

When you combine the beginning HTML code from listing 5.1 with the HTML code in listing 5.2, you get the HTML document code shown in listing 5.3.

The user's browser renders this code as shown in figure 5.4. The HTML document in listing 5.4 has becomes a simple, working HTML interface for your firm's CGI application.

Figure 5.4 : The complete HTML interface for the stock- quote CGI script includes five five-character fields, so the user can type in symbols for five stocks.

Creating the Marketing Questionnaire

Now that you've completed the stock-quote project, the marketing department wants to create a follow-up form to the CGI interface page. They want to ask users about their stock-buying habits and request comments and other demographic information.

This new project varies a little from the first HTML interface document. This time, you'll be requesting more information from users and returning a confirmation and thank-you page in return.

Again, the IT department will write the Perl CGI script to handle this information, so you can start on the questionnaire project immediately.

Preliminary Information

You need to start by asking the users for some information. The marketing staff has provided you with a laundry list of information to ask users. For example, the staff wants to know

I stated during the first project that I assume you already know most of the HTML elements that you need to create this form. So go ahead and fire up your favorite HTML editor, and create the beginning of the questionnaire interface page. Your finished example may look something like the HTML code in listing 5.4.

You start the actual HTML form after the last line in listing 5.4. To make this process easier, take each group of questions that marketing wants to ask and compose the HTML code for it. Then you can put this code together in a complete HTML document.

Selecting Only One Element

Begin with the group questions: age group, gender, and income group. Do you notice that these types of questions can have only one answer? You can't be in the 20-29 age group and the 30-39 age group at the same time. Because you can be in only one group at a time, using a radio <INPUT> tag for this type of information makes sense. With that in mind, listing 5.5 shows proposed HTML code for handling these types of questions.

Figure 5.5 shows how the user's browser will render this code . It's shaping up quite nicely.

Figure 5.5 : Listing 5.5 translates into this page in Netscape Navigator.

The next question that marketing wants to ask is how many people are in the respondent's household. You can handle this question using a simple sized text input field, as follows:

Selection Input Fields

The next question for the comments form, current stock portfolio size, could be handled with a couple of different input types. You could use radio buttons like you used earlier, which would work well. But I think a slightly better choice would be another input tag not covered yet-the <SELECT> tag, and its companion, <OPTION>. You use the <SELECT> tag as follows:

This line tells the user's browser to start a selection list, and the NAME of this variable is portfolio. Not much to tag so far, but you need to add the <OPTION> form elements. These tags contain the values that will populate a pop-up menu (or a multiple select scrolling list box) that the user can select from. An example of the HTML format for <OPTION> elements is

In this example, you can select only one option at a time. The default form element for <SELECT> is a pop-up menu. If you want to allow users to select multiple items from a list, add the MULTIPLE attribute to <SELECT>, like this:

This alternative would allow users to select multiple options from a list in a scrolling list box. The preceding line makes the <SELECT> tag work like check boxes.

Figure 5.6 shows how the HTML interface is going to be rendered on the user's browser now. Your page is starting to take shape.

Figure 5.6 : <SELECT> and <OPTION> HTML code has been added to the questionnaire example.

When you use the <SELECT> and <OPTION> tags within your HTML form, the user's browser displays it as a pop-up menu or a pull-down menu, depending on which platform your browser is on (see fig. 5.7). If the user clicks the down arrow, the additional options appear, and the user can then select one of the displayed options. Depending on what browser the user has, these options might be rendered differently. As with all HTML documents, you can't be sure how your page is going to be viewed.

Figure 5.7 : You can use the <SELECT> tag to create a pop-up menu.

More Boxes and Buttons

The marketing people also want to know about the clients' stock interests, which magazines they read, and whether they're interested in a bonds-quoting service. You can handle these types of questions using simple check box and radio <INPUT> elements, as shown in listing 5.6.

Listing 5.6 contains pretty straightforward HTML code now because you learned about check box and radio <INPUT> types earlier in the chapter. You also could have used the <SELECT> tag and MULTIPLE element to achieve the same basic result. Instead, the check boxes and radio buttons are used here so that users can see all the choices at once (see fig. 5.8).

Figure 5.8 : The example questionnaire now contains check boxes.

Miscellaneous Text Areas

When you get to the last few questions that marketing wants you to ask on your comments form page, you need to use a new type of input element called <TEXTAREA>. This element lets you define a text region on the users' browsers into which they can type multiple lines of text.

<TEXTAREA> is a straightforward HTML tag also. For example, look at the following lines of HTML code:

The ROWS attribute tells the browser how many horizontal rows to display. The COLS attribute tells the browser how wide to make the <TEXTAREA> in characters. The text Type your comments here is displayed within the defined <TEXTAREA>. </TEXTAREA> is the closing tag for TEXTAREA, and indicates where any default text for the area ends. The user's browser will render this code to look what's shown in figure 5.9.

Figure 5.9 : A <TEXTAREA> input element allows respondents to leave lengthy comments.

The <TEXTAREA> tag is similar to <INPUT> text type's VALUE attribute.

With the addition of a <TEXTAREA> tag, the rest of the code for the HTML questionnaire looks something like listing 5.7.

The Finished Questionnaire

Listing 5.8 shows the complete listing for the HTML comments form. Figure 5.10 shows how the final form will look on the browser. The questionnaire should help your marketing department make some better decisions on where to spend its advertising budget.

Figure 5.10 : Here's the finished HTML questionnaire, as viewed from Netscape Navigator.

The Good, the Bad, and the Ugly

As you've surfed around the net, you've probably encountered Web sites that haven't used forms appropriately. When you start working with HTML forms extensively, look around at the sites that use simple, clean, and effective HTML forms.

Using HTML forms for some CGI user interfaces is a challenge. I've seen some HTML forms that were so bad-or, should I say, "usability challenged?"-I wouldn't use them.

You should spend some time looking at other sites' forms. See whether the forms actually do their jobs or seem to be thrown together. If you have to throw together an HTML form quickly, that's one thing. To never go back to clean it up is another.

The Good

Look at the form in figure 5.11. This form is from a popular Web search system. I call this one a good example of form usage. The form is clear, concise, and simple. You know exactly what it's for.

Figure 5.11 : A good form page is clear and simple.

The Bad

The example in figure 5.12 is from someone's personal home page. (I have changed the name to protect the guilty.) Why would anyone create a page this bad? It doesn't flow at all.

Figure 5.12 : A bad form has no flow and bad field placement.

The Ugly

An ugly HTML form interface is better any day than a bad HTML form interface. Just because an HTML form is ugly doesn't mean that it's not highly usable. Take, for example, the form shown in figure 5.13. This HTML page lacks character-it has no pizzazz or spark. It's used as an HTML interface for a CGI application for a government agency.

Figure 5.13 : This ugly example flows well enough but could use some color.

Can you use it, though? You sure can. It may lack character, but it handles data flow easily. So when users come across it, they can enter data quickly because the form is easy to understand. You can easily see what the form wants from the users.

But to avoid creating bland or ugly HTML forms, put a splash of color-whether it be a fancy horizontal rule or a graphic logo-after you have the data flow correct. Then try out the page and have your friends try it out.

SE USING CGI

Add To MyInformIT

< Back Contents Next >

Featured Author

Featured Book