Chapter 11. Working with Forms

CONTENTS

 

•  How Forms Work in the Browser
•  Creating Forms in Dreamweaver
•  Behaviors and Forms
•  Strategies for Working with Forms
•  Dynamic Data and Forms
•  Taking Forms Further
•  Interview: Adrian Senior
•  Server-Side Scripts for Processing Forms
•  Summary

When a web site and its visitors can respond to one another, its usefulness increases greatly, both to the user and the site owner; this is often referred to as interactivity.

Forms are one of the primary tools that enable the web user to talk to the site's administrators.

A form allows you, the developer, to ask structured questions of the visitor, enabling you to elicit desired information. With a form, you can just ask for the visitor's name and email address; you also can have visitors take a survey, sign a guest book, provide feedback on your site, or even make a purchase. Forms are standard tools for the web designer.

Topics covered in this chapter include how forms work in the web environment, the basic HTML for building forms, how to create forms with Dreamweaver, how to use behaviors with forms, the secrets of building attractive, user-friendly forms, and some special additions and enhancements for forms.

Along the way you'll have the opportunity to work through a series of exercises that show you how to build a simple mail form, add more complex features to it, format it with CSS, and get it ready to be processed by a server-side script.

How Forms Work in the Browser

The HTML code you create in Dreamweaver (or any other web-authoring program) is only part of what is required for a form to do its job. Forms require a script (a set of instructions, generally a text file, that is executed within an application) in order for the information input to the form to be processed.

Form-Processing Scripts

The most common way to process form data is a Common Gateway Interface (CGI) script. CGI scripts are typically written in Perl or another programming language, possibly C++, Java, VBScript, or JavaScript.

Forms also can be processed by server-side technologies such as ASP, ASP.NET, ColdFusion, PHP, or JSP, which function essentially in the same way as CGI scripts. In conjunction with these technologies, forms are commonly used to collect information to be added to databases. (See Chapter 26, "Introduction to Dynamic Dreamweaver.")

Before creating interactive forms, check with the administrator of the server where you plan to host the web site and find out what type of scripting technology is supported. Perl CGI scripts are very commonly supported, and some host companies will even provide these scripts already set up for use on their servers.

The specifics of setting up scripts are beyond the scope of this book; but at the end of the chapter, you'll find some web resources that will point you in the right direction.

HTML Forms

The HTML code for form creation is not very complex. Even if you manage to do much of your web page building with Dreamweaver without looking at the source code, it's particularly helpful in the case of forms to at least be somewhat familiar with the tags and attributes involved. When it comes time to troubleshoot a form that doesn't work as it should, a careful look at the HTML might reveal the error.

Tip

As you build the forms in the exercises in this chapter, and as you build your own forms, you either should work in Code and Design view so that you can see the HTML source code as well as Design view, or you should switch back and forth frequently from Design view to Code view and keep an eye on the code Dreamweaver writes for you.

The <form> tag

Forms begin and end with the <form>...</form> tag pair. Between these tags will usually be some normal HTML markup for formatting purposes, and form controls the text fields, check boxes, and other elements used to gather information. Dreamweaver refers to these elements as form objects.

Note

In some situations, a form might not require the <form> </form> tag pair, such as a client-side-only form, which doesn't involve sending information to a server at all. Some browsers, however, particularly Netscape up to and including version 4.7, will not display form elements outside of a <form> block, so it's best to include it.

The <form> tag has seven possible attributes, as shown in Table 11.1.

Table 11.1. Attributes of the <form> Tag

Attribute	Function of Attribute
name	Assigns an identifier to the entire form element. This value is particularly useful when using scripts that reference the form or its controls.
action	Specifies the URL to be accessed when the form is being submitted. The URL might be to a CGI program, or to an HTML page that contains server-side scripts.
method	Forms might be submitted by two possible HTTP methods: GET and POST. This attribute specifies whether the form data is sent to the server appended to the ACTION attribute URL (GET) or as a transaction message body (POST).
target	Allows a window or frame destination other than the current one to be specified as the location to load the HTML page that has been designated to be returned by the server after the form data is processed.
enctype	Sets a MIME type for the data being submitted to the server. For typical form submissions sent by the POST method, the default MIME type is the correct one.
accept	Enables you to specify one or more MIME types for permissible files to be uploaded to the server when using INPUT elements of the type FILE. Provides client-side validation of a file type.
accept-charset	Advises the server about which character sets it must receive from a client form.

Here is an example of an opening <form> tag using hypothetical attribute values, to demonstrate the syntax:

<form name="order_form" method="get"  action="http://www.mydomain.com/cgi/FormMail.pl">

Tip

When naming forms and form elements, keep a few things in mind. First, don't use spaces or special characters. Second, it is a good idea to use names that clearly identify the form or element's role. Third, develop your own naming conventions, and be consistent. Either don't use capitals at all, or use them in a consistent way; either don't abbreviate English words at all, or abbreviate in a consistent way; either use underscores between words, or run the words together. This helps you to remember the names you create and avoid typos. Finally, be aware that scripting languages have certain reserved words that have special meaning and can cause problems. The word date is a common example. You might want to research which reserved words exist in the scripting language you're using, especially if you run into problems that seem to have no other explanation.

The <input> tag

In between the <form>...</form> tags, a form will have <input> tags with various attributes. It also might have <select>, <option>, and <textarea> tags.

The <input> element provides an object that can collect user data, such as a text field, a check box, a radio button, a list, or menu; a Submit button also is written using the <input> tag.

The <input> element accepts numerous attributes; the type attribute of the <input> tag determines the kind of control that appears on the page. The type attribute can have a number of different values, including checkbox, radio, text, submit, and reset. The <textarea> element produces a multiple-line text box area. <select>, along with <option>, produce drop-down menus and list boxes. Each of these kinds of form objects is shown in Figure 11.1.

Figure 11.1. The different types of form objects shown in a browser window.

Creating Forms in Dreamweaver

Dreamweaver makes building HTML forms very easy. All common form tags can be added using the Forms tab of the Insert bar. The same objects also are available by choosing Insert > Form as well as Insert > Form Objects from the main menu. Figure 11.2 shows the different buttons available from the Forms tab of the Insert bar.

Figure 11.2. The Forms tab of the Insert bar.

The basic steps involved in building an HTML form with Dreamweaver are as follows:

1. Add a <form> </form> tag pair, and set its attributes using the Property inspector. The placement of the form tag will be displayed in the Dreamweaver Design window as a red dashed line.

2. Between the <form> tags, if desired, add a table to give your form elements a neat layout.

3. Add elements one by one, using the Property inspector to set their attributes. You'll usually need to add ordinary HTML text labels to the form objects; in other words, if a text field is designed for the user to type in his name, you'll want to place the word Name next to the form field to identify its intended purpose.

4. Add a Submit button, and once again, use the Property inspector to set its attributes.

Exercise 11.1 Building a Simple HTML Form

In this exercise, you build a simple HTML form that includes several <input>. As you go through the steps, feel free to experiment with the different tags and attributes. See what results you have in the Document window, and in Code view as well.

If you do experiment, however, it's probably best to return each object to the values specified in the exercise, because later exercises build on this one. In Exercise 11.2, you'll add several more form elements to this page, producing a longer and more complex form.

Before you start, copy the chapter_11 folder on the CD to your hard drive. Define a site called Chapter 11, with this folder as the local root folder.

1. From the chapter_11 folder, open the file form.html.

2. Place the cursor after (below) the box with the heading and text. In the Insert bar, bring the Forms tab to the front. Click the Form Object icon. You should see a red dotted line forming a narrow rectangle just below the text box. If you don't see this red dotted line, choose View > Visual Aids > Invisible Elements. This represents the <form> block in your document; all form elements need to be placed within this red dotted line (see Figure 11.3). For now, you won't set any attributes to the <form> tag.

   Figure 11.3. The Exercise document with the <form> block shown by a red dotted line.

   

3. Now place an HTML table within the <form> block; this table will enable you to align the form elements nicely. Place the cursor inside the <form> block and choose Insert > Table from the main menu. In the Insert Table dialog box, give your table 7 rows, 2 columns, a width of 70 percent, a border of 0, cell padding of 5, and cell spacing of 0. Click OK to insert the table in the document; while it is still selected, in the Property inspector, choose Align > Center. In the upper-left table cell, type Name.

4. Place the cursor in the upper-right table cell; you can use the Tab key to step from cell to cell within a table in the Dreamweaver Document window, left to right, top to bottom. Click the Text Field button in the Insert bar.

5. Notice that a text field has been inserted. As with many elements in Dreamweaver, while it's still selected, the Property inspector displays a number of options and attributes associated with the element. On the left side of the Property inspector is a field displaying the words textfield; here you can specify a name for the text field. Name it visitor_name.

6. Give the text field a Char Width (character width) of 30; this adds an attribute size="30 to the <input> tag. Leave the other fields in the Property inspector at their default settings. Your form should look like Figure 11.4.

   Figure 11.4. The exercise with one text field and its label.

   

7. The label Name is a long way from the field it identifies. To fix this, place the cursor in the table cell with the word Name. In the tag selector, at the bottom of the Document window, select the rightmost <td> tag. In the Property inspector, set Horz (horizontal cell alignment) to Right. The text Name should now be placed on the right side of the cell, as shown in Figure 11.5.

   Figure 11.5. Aligning the text label within its cell.

   

8. All of your form labels will be in cells in the table's left column, and you'll want them all right aligned. This can be done in one operation. It requires selecting multiple table cells, as follows: Place the cursor in the left cell of the second row. Click, and holding the mouse button down, drag downward across all seven left-hand cells. Each cell will "light up" with a black border as you select it. With all seven cells selected, in the Property inspector, choose Horz > Right.

9. In the second row, type Email Address into the left cell, and in the cell on the right, add another text field. Give it the same attributes as the Name text field but a unique name: email. The form object's name goes in the field on the far left in the Property inspector.

10. In the third row, left cell, type the text Please send me information on these services. In the right cell, you will add a number of check boxes.

11. To add the first check box, place the cursor in the right cell of the third row and click the Checkbox button. A check box will appear. With it still selected, in the Property inspector, fill in its name in the field on the far left; use web_design_info.

12. The text you type into the Check Value field will be the text that will be sent with the user's form data if the user checks this check box. While the check box is still selected, fill in the Check Value field with the word yes. In this case, if the user checks this box, the data sent will indicate that the check box web_design_info has a value of yes.

13. In the Document window, directly to the right of the check box, type Web Design.

14. After the words Web Design, press Shift+Enter to create a line break, and add another text box. Give this one the name web_hosting_info and the value yes. In the Document window, add the label Web Hosting to the right of the second check box. Your document should now look like Figure 11.6.

    Figure 11.6. The exercise with check boxes added.

    

15. In the fourth table row, you'll add radio buttons to get the answer to a yes-or-no question. In the left cell, type the text I have an existing web site. With the cursor in the right cell, click the Radio Button button on the Insert bar.

16. With the radio button still selected, in the Property inspector give the radio button the name have_web_site and the Check Value yes.

17. Press Shift+Enter to add a line break, and add another radio button. Give it the same name as the preceding radio button; a radio button group must all have the same name. Give it the Check Value no.

18. In the Document window, next to the first radio button, type Yes; next to the second radio button, type No. Your page in the Document window should now look like Figure 11.7.

    Figure 11.7. The exercise page with radio buttons added.

    

This completes Part I. You have left empty table rows for the elements you'll add in Exercise 11.2. Save your document and view it in a browser.

Note

New to Dreamweaver MX is the Radio Group object in the Forms tab of the Insert bar. Clicking the Radio Group button opens the Radio Group dialog box, where you can specify all the radio buttons in a group at once, giving them the required common name. Using this function allows you to add both the values and the HTML labels for each radio button, and to choose whether or not to separate the buttons with an HTML table, or simply with line breaks.

Exercise 11.2 Scrolling Lists, Drop-Down Menus, and a Submit Button

If you haven't done so yet, copy the chapter_11 folder on the CD to your hard drive. Define a site called Chapter 11, with this folder as the local root folder.

1. Now you add a menu. Open your document from Exercise 11.1, form.html. Place the cursor in the fifth row, left cell, and type Select the type of web site you are considering. Place the cursor in the right cell and click the List/Menu button on the Insert bar.

   Note

   

   Form lists and form menus are different; read about their best uses in Table 11.2. In Dreamweaver, however, you insert them using the same button and use the same Property inspector to set their attributes and properties.

2. With the List/Menu object selected in the Document window, in the Property inspector, leave the default setting of Type - Menu, and name this menu type_of_site.

3. Click the List Values button to open the List Values dialog box, as shown in Figure 11.8.

   Figure 11.8. The List Values dialog box.

   

4. Click the plus (+) button and just beneath Item Label, type the words you want to appear in the form menu. Start with Static site for this item. Beneath Value, type the value you want to be submitted with the form data. Usually this will be the same as the Item Label, but in some situations they could differ. Here, for Value, type Static site again.

5. Add a second menu item with both the Label and Value Data-driven site.

6. If you like, use your imagination and add several more menu items. With a menu, the user will be able to choose only one item; you'll want to keep that in mind when building real-world menus; but here, add several more items so that you can see how a menu object looks and behaves. Click OK to close the dialog box and enter the menu in your document.

7. Save the document and view it in the browser. It should look like Figure 11.9.

   Figure 11.9. The exercise page with a menu object added.

   

8. Next add a list object. In the sixth row, left column, type the text Select some basic features you might want to include. Place the cursor in the right cell and click the List/Menu button on the Insert bar again. With the object still selected, in the Property inspector, select Type > List. Name it features, and give it a height of 3. This setting determines the number of list items that will be visible without scrolling.

9. Check Allow Multiple Selections, and then click the List Values button as you did with the menu object. In the List Values dialog box, add a number of list items, giving each the same Value as the Item Label. Start with Company logo, Descriptive text, Feedback form, and Guestbook; and, if you like, use your imagination and add a few more. Save your document and view in the browser. It should look like Figure 11.10.

   Figure 11.10. The exercise page in the browser at Step 9.

   

   Tip

   

   When adding multiple list items in the List Values dialog box, you can use the Tab key to go from an Item Label field to its Value field and then on to the next Item Label field.

10. Add the Submit button. Place the cursor in the left cell of the seventh row and click the Button button. With the object still selected, in the Property inspector, choose the options you need. For example purposes, the default name Submit and default label Submit are adequate, but try experimenting with the Label; you might use Submit your request now or the like.

11. For the Action, in this case, choose Submit. Reset would be chosen if you wanted to supply the user with the option to wipe his form clean and start over. You would choose None if you are using a script that provides a different action when the button is clicked.

12. Save the document and view it in a browser. It should look like Figure 11.11.

    Figure 11.11. The finished exercise page.

    

Note

Form buttons can be used for functions other than submitting a form, such as resetting the form to its defaults (so that a user can undo mistakes and start over) or calculating an order based on data submitted.

Tip

You can make more creative Submit buttons by using the Image Field object and inserting a graphic file of your choice.

Behaviors and Forms

Dreamweaver behaviors are some of its most powerful and useful features. A behavior enables the visitor to interact with a web page to change it or to cause certain tasks to be performed, and consists of a combination of HTML and JavaScript written by Dreamweaver. Chapter 16, "Getting Interactive with Behaviors," looks at Dreamweaver behaviors in depth.

Behaviors can be attached to forms and form objects by using any of the behaviors that appear in the Behaviors panel when the form or object is selected. This chapter discusses two behaviors commonly used with forms, Validate Form and Set Text of Text Field. Note that the scripting being used here is client-side, as opposed to server-side, scripting; all the action takes place before the page is submitted to the server.

Tip

When applying behaviors, make sure that every form object in your document (and every other object) has a unique name. If you use the same name for two objects, behaviors might not work properly.

Validate Form

The Validate Form behavior (see Figure 11.12) checks the contents of specified text fields to ensure that the user has entered the correct type of data, or that he has at least entered some data.

Figure 11.12. The Validate Form dialog box.

You can attach this behavior in two ways:

• Attach it to the individual text fields with the onBlur event to validate the fields as the user is filling out the form.

• Attach it to the form itself with the onSubmit event to evaluate several text fields simultaneously at the point when the user clicks the Submit button.

Attaching this action to a form prevents the form from being submitted to the server if any of the specified fields contain invalid data.

Note that only text fields can be validated. The behavior can check to be sure that the field is not empty (check Required) that it is an email address (check Email), that it is a numeric value (check Number), or that it is a numeric value within a specified range (check Number between and fill in a starting and ending numeric value).

Exercise 11.3 Attaching the Validate Form Behavior to the onSubmit Event

In this exercise, you attach the Validate Form behavior to the onSubmit event to check the text fields in your form before submitting it to the server. This exercise builds on Exercises 11.1 and 11.2, which should be completed before you proceed with this exercise.

If you haven't done so yet, copy the chapter_11 folder on the CD to your hard drive. Define a site called Chapter 11, with this folder as the local root folder.

1. Open your form.html document from Exercise 11.2. In the tag selector at the bottom of the Document window, select the <form> tag. If you don't see it there, place the cursor within the red dotted lines in the Document window and it should appear.

2. From the main menu, choose Window > Behaviors, or click the Behaviors icon on the Launcher bar, to open the Behaviors panel. Click the plus (+) button, and from the drop-down menu, choose Validate Form, which opens the Validate Form dialog box (refer to Figure 11.12).

3. Select the text field you named visitor_name. Select Required so that the field has to contain some data. From the Accept options, select Anything.

4. Then select the text field you named email. Again, select Required. This time, however, from the Accept options, select Email address. This will require that this field at least contain an at sign (@) to be accepted.

5. Click OK to insert the behavior. Note that if you would like to edit any aspect of this behavior, you can select the <form> tag, and in the Behaviors panel, double-click the Validate Form action where it appears in the panel's main window to reopen the Validate Form dialog box.

6. Save the document and preview it in a browser. You can test the form to some extent without having it actually connected to a script; when you press Submit, the browser will return an error message, because you haven't specified a place to submit the data. Before you receive that error message, however, you can observe the Validate Form behavior in action. Try submitting the form without filling in a name; you should get an error message in the form of a small gray browser pop-up box (see Figure 11.13) Then try it with a name filled in, but with an invalid email address containing no at sign (@); you should get another error message. If you fill in these two fields with valid data and click Submit, you shouldn't get any more validation error messages, but might still receive an error message indicating that the form doesn't have a correct action specified. Don't worry about this; until the form is hooked to a script or application, it can't actually be used to submit data.

   Figure 11.13. A browser's form validation error message.

   

Set Text of Text Field

The Set Text of Text Field behavior replaces the content of a specified text field with the content you specify.

Any valid JavaScript function call, property, global variable, or other expression can be embedded in the text. A JavaScript expression must be placed inside braces ({}).

Exercise 11.4 Applying the Set Text of Text Field Behavior to a Single Text Field

In this exercise, you apply the Set Text of Text Field behavior to a single text field. This exercise can be done independently of the others in this chapter.

If you haven't done so yet, copy the chapter_11 folder on the CD to your hard drive. Define a site called Chapter 11, with this folder as the local root folder.

1. From the chapter_11 folder, open the file set_text.html. You have a head start on this page: a form with a single form field, a text field named page_url. Select the text field and open the Behaviors panel. Click the plus (+) button and, from the drop-down menu, choose Set Text > Set Text of Text Field. This opens the Set Text of Text Field dialog box (see Figure 11.14).

   Figure 11.14. The Set Text of Text Field dialog box.

   

2. Notice that the text field, page_url, displays in the field at the top of the box. If other text fields were present on the page, you would need to choose a particular text field to which to apply the behavior. In the New Text box below, type the text you want to appear in the text field. For this example, use the following:

   This page's URL is {window.location}

3. Click OK. With the form field selected, check the Behaviors panel to see that the behavior you've just added is displayed in the main panel window. By default, its action should be set to the onBlur event; this means that the behavior's action will be triggered when the focus is put on the text field, and then removed from it.

4. Save the document and test it in a browser. Click in the form field and then somewhere else on the page; the form field should fill with text reading something like this:

   This page's URL is file:///C:/idmx/chapter_11/TMPsx81staup5.htm

   If you see something like this in the text field, you've completed the exercise correctly.

Strategies for Working with Forms

As you have seen, building a form with Dreamweaver is fairly straightforward, but creating really useful, attractive forms requires a little more thought and planning.

The User Interface

As with any aspect of a web site, the user interface is crucial, but it is especially so in the case of forms. Filling out a form is not a favorite activity for most web visitors; when forms are nice-looking and easy to understand and use, they're more easily tolerated.

Use the Right Input Type for the Job

Choosing the appropriate input type for each form element requires some analysis of the kind of information being collected; Table 11.2 describes the best uses for each.

Table 11.2. Best Uses for Form Input Types

Input Type	Best Suited For
Text field	A single word or short phrase response, such as a name or street address.
Multiple-line text fields	A response that might require a full sentence, several sentences, or even several paragraphs.
Password field	Inputting passwords; the browser displays the input as asterisks or bullets to preserve privacy.
File field	Enabling the user to type, or to browse for, a file to upload.
Hidden field	Gathering or sending information along with the form data without displaying it to the user.
Check boxes	A group of yes-or-no options, when more than one can be chosen.
Radio buttons	A group of yes-or-no options, when only one can be chosen.
Scrolling list	When there are many choices and limited space; when more than one option needs to be able to be chosen; when you want to display x number of options on the page before the user clicks or scrolls.
Drop-down menu	When space is very limited; when only one option can be chosen; when it's acceptable to have only one option display by default.

Labeling and Positioning

Even seemingly small factors can make a big difference in the usability of a form. Form controls should be labeled unambiguously; try putting yourself in the position of the end user, and see whether your labels are clear and make sense. If you want the user to type her full name, for example, you're better off using the label Full Name than Name, because many forms ask for the last name and first name separately.

Submit buttons and other form buttons, such as Reset, should also have labels whose meaning is obvious. Submit Now or Send Your Information Now can be good choices, especially when your users might be inexperienced with the web in general; that kind of language helps make clear what will happen when the button is clicked.

The positioning of form controls in relationship with their labels is also important. Take a critical look at any form you're creating to see whether it's entirely clear which label goes with which input item. Don't give the user anything to figure out; everything should be as plain and intuitive as possible.

Text Fields and Netscape 4

If you preview the form you built in Exercises 11.1 and 11.2 in Internet Explorer, the text fields should look about the same as they do in the Dreamweaver Document window. You specified that they should have a size of 30, and the form field IE displays looks as if it is approximately the same width as 30 text characters in the font size you've declared for the page. (The font face and size for the page is set with a document-side style sheet; you can see it in the page's source code in the document <head>.)

If you have a copy of Netscape 4 (any version), and preview the form page with it, you'll see that the form's text fields appear much longer. This is because Netscape 4.x calculates the width of a form field a different way than IE does. Netscape 4.x takes the specification of 30 characters and uses the widest possible character in the default monospace font as the unit of measurement, as shown in Figure 11.15.

Figure 11.15. Netscape 4 (top) renders text fields much longer horizontally.

In the case of this form, the longer form fields don't present a serious problem. If you need a 100-character text field, however, Netscape 4 will display it much wider than a typical browser window width. This problem is inconvenient at best, and serious at worst.

It can be solved with CSS by creating a custom class and applying it to the form fields. The custom class should declare the font to be a monospace font of about 11 or 12 pixels, and is applied directly to the <input> tag. Refer to Chapter 13, "Using Cascading Style Sheets," for an in-depth treatment of CSS.

Form Layout

Forms present their own unique layout challenges, and HTML tables are still the most widely used tools for making form elements behave on the page. By placing form controls and their text labels in separate table cells, they can be made to line up neatly and vertically. In Exercise 11.1, you used a table to align form elements and text for a readable form with a good appearance.

A background color applied to certain table cells can make form fields stand out more to the eye, and just provide some interest and variety. Table borders, applied with the border attribute to the <table> tag, add borders to all cells as well, and can create order in more complex forms. Cell padding can be used to space form elements ideally.

In Exercise 11.5, you experiment on the form you built in Exercises 11.1, 11.2, and 11.3, adding some table formatting.

Exercise 11.5 Using Table Formatting to Make Attractive, Readable Forms

If you haven't done so yet, copy the chapter_11 folder on the CD to your hard drive. Define a site called Chapter 11, with this folder as the local root folder.

1. Open the file form.html you built in Exercise 11.1.

2. Select the table that holds the form elements, and in the Property inspector, in the Bg Color field, type #DFDFDF. Press Enter. Save and view the document in a browser. You might want to try some other colors; click the color chip in the Bg Color field and use the color picker to experiment.

3. Select the table again, and in the Property inspector, in the Border field, enter the number 1, and press Enter. When no color is specified, most browsers render a table border as gray and 3D. Select the table again, and this time apply a border color. Preview the document. Try out various border colors and background colors in combination, or you might prefer to leave out the border entirely for this simple form.

4. Select the table again, and use the Cell Padding field in the Property inspector to adjust the number of pixels between the content and the border in each cell. You gave your table 5 pixels of cell padding in Exercise 11.1; you might prefer more or less.

5. For a pencil-thin border around only the table itself, try adding an inline CSS declaration to the table tag. First, set the table's border attribute to 0. Select the table and press Ctrl+T to open the Quick Tag Editor. The Quick Tag Editor has three modes: Edit Tag, Wrap Tag, and Insert HTML; pressing Ctrl+T cycles through these three modes. Press Ctrl+T once or twice more until you see Edit Tag. The tag should look something like this, although your experimentation might have changed some of the values:

   <table WIDTH="70%" CELLSPACING="0" CELLPADDING="5" ALIGN="CENTER"  BGCOLOR="#DFDFDF">

   Place your cursor just before the closing bracket, and type in the following CSS code:

   STYLE="border: 1px solid #000000">

   Press Enter to close the Quick Tag Editor and add the code you've just typed.

6. Save the document and preview it again. In Internet Explorer 4.0 or later, you should see a nice thin black border around the table (see Figure 11.16; unfortunately, Netscape 4 versions and earlier don't support this CSS style).

   Figure 11.16. The exercise form table with a background color and a thin CSS border.

   

7. Continue to experiment with various table attributes and settings until you're satisfied with the look of your form.

Dynamic Data and Forms

Forms are used heavily in dynamic sites for collecting information. Search pages, login pages, information update pages all use forms to collect user input and either query or edit the data source.

If you only need the form to collect information, you don't need your form elements to be dynamic. But if you also want the form to present information from the data source a pop-up menu of choices based on database contents, for instance, or a personal data page that users can check and update you need to use dynamic data to determine the contents and status of the form elements.

Dynamic List/Menu

The trick to creating a concise pop-up menu or list with dynamic entries is to eliminate all duplicates from the data source. (Even if your database includes 300 necklaces in its stock table, you probably only want the "Necklaces" entry to appear once in the list.) To create a dynamic list/menu with no duplication:

1. When collecting the Recordset for the document, after you have chosen which fields to collect, go to the Advanced tab of the dialog box. Edit the SQL query to add a GROUP BY clause, grouping by the field that you plan to use in the dynamic list/menu. Note that, if there is an ORDER BY clause, it must remain at the end of the query.

2. Add a regular form Menu object and click the Dynamic button in the List/Menu Property inspector.

3. In the dialog box that appears, choose each list item's name and value from Recordset fields.

Dynamic Check Box

A dynamic check box will appear selected or not, depending on a field value in the recordset. To create a dynamic check box:

1. Insert a regular check box into your form (Insert > Form Objects > Checkbox). Using the Property inspector, give the check box a name you'll remember.

2. In the Server Behaviors panel, click the plus (+) button and choose Dynamic Form Elements > Dynamic Checkbox.

3. In the dialog box that appears, choose your check box's name. Then specify which Recordset field should be examined, and enter a value that field must be equal to for the check box to appear as checked. The dialog box only allows for comparisons based on equality (no less than, more than, and so on).

Dynamic Radio Button

A dynamic group of radio buttons will have one of their members selected, depending on a field value in the Recordset. To create a dynamic radio group:

1. Insert a group of radio buttons, as you normally would (Insert > Form Objects > Radio Button or Insert > Form Objects > Radio Group). Use the Property inspector to give the group a name, and each button a unique value.

2. In the Server Behaviors panel, click the plus (+) button and choose Dynamic Form Elements > Dynamic Radio Group.

3. In the dialog box that appears, choose your radio group's name. Then specify a Recordset field each button in the group should be compared to, to determine if it will be selected in the form.

Dynamic Text Field

Dynamic text fields will appear in the form filled with text from a specified Recordset field. To create a dynamic text field:

1. Insert a text field, as you normally would (Insert > Form Objects > Text Field). Use the Property inspector to give the text field a name you'll remember.

2. In the Server Behaviors panel, click the plus (+) button and choose Dynamic Form Elements > Dynamic Text Field.

3. In the dialog box that appears, choose your text field's name. Then specify the Recordset field whose value should appear in the text field.

Taking Forms Further

Forms can be both made more accessible and dressed up visually with some of the newer features discussed in this section. Most of what is presented here will require some hand coding. Again, even the beginner especially the beginner should venture into Code view, get accustomed to the look and syntax of HTML code, and try some hand coding.

Making Forms Accessible

HTML 4.0 introduced some new elements and attributes that provide improved support for accessibility in forms, although they are not fully implemented by all browsers as of this writing. These include the <label> element and the accesskey and tabindex attributes. Dreamweaver MX makes it easy to include these accessibility attributes in forms (and in other page elements, as well) with its new Accessibility preferences.

The <label> Element

Most form <input> elements are given text labels that are associated visually with form control in the browser's display, but these labels are not actually part of the element's tag. The <label> element makes it possible to logically (rather than just visually) associate the labels with the controls they describe. This is particularly useful to speech-based browsers, which can then clearly connect the two.

The <label> element can be applied in two ways. In the first method, the form control tag is enclosed by the opening and closing <label> tags:

<label>Phone Number:  <input TYPE="text" NAME="PhoneNumber" >  </label>

However, this first method sometimes can't be used, because a form label and the control it describes are often contained within two separate table cells.

When the label and its control are in different table cells, the second method can be used: the id attribute of the control element is assigned to the for attribute of the label element:

<table>      <tr>          <td>          <label for="PhoneNumber" >Phone Number: </label>          </td>          <td>          <input type="text" ID="PhoneNumber">          </td>      </tr>  </table>

The accesskey Attribute

The accesskey attribute defines a keyboard shortcut, or accelerator key, which activates an element's form control. Depending upon the operating system and browser, a modifier key such as Control, Alt, or Command might need to be pressed with the access key to activate the link. accesskey does not work in Internet Explorer for the Macintosh.

accesskey can be used as an attribute for <label>, <input>, <button>, or <legend>. When it is used with <label>, it is the form control associated with the <label> element, which is focused, not the label.

A common convention used in a Windows GUI is to highlight the letter that will activate the field. The HTML 4.0 specification states that browsers should provide their own type of highlighting for an access key, but the browsers are not yet consistent in implementing this. You might want to dictate this highlighting yourself by underlining the letter using HTML, as in:

<label ACCESSKEY="p"><u>P</u>hone Number:  <input TYPE="text">  </label>

The tabindex Attribute

A form field must be focused for data to be entered into it; in other words, keystrokes or mouse clicks need to be directed to that particular control. If the user clicks in the field, that field gets the focus. The user also can use his Tab key to proceed from one focusable element to another on the page.

The <input> types button, check box, file, password, radio, reset, submit, and text are all focusable elements. The <input> tag will accept the attribute tabindex with a numeric value, enabling you to specify the tabbing order in a document. (Unfortunately, Netscape 4 browsers do not support this attribute.)

Tip

tabindex will accept a numeric value between 1 and 37,767.

Focus starts with the element with the lowest tabindex value and proceeds in sequential order to the element with the highest value, ignoring the element's physical location on the page or location in the source code.

The code would look something like this:

<input type="text" tabindex="3">

The attributes discussed above, and all other attributes associated with a form element, can be edited using Dreamweaver MX's Edit Tag feature. Select the form element and either right-click and choose Edit Tag, or choose Modify > Edit Tag. This opens the tag editor dialog box, as shown in Figure 11.17.

Figure 11.17. The tag editor dialog box.

Four categories of attributes are listed in the dialog box's left-hand column. Clicking a category provides you with a list of possible attributes for the element, allowing you to fill in values for any you choose.

Dreamweaver's Page Accessibility Features

If you choose, you can set your preferences so that Dreamweaver MX will remind you whenever a form element for which accessibility options are available is added to the document. Before the element is inserted, the Accessibility Attributes dialog box opens, allowing you to set the <label> element, the accesskey attribute, and the tabindex attribute.

To turn on this feature, choose Edit > Preferences > Accessibility and check Form Objects.

Using CSS with Forms

Form fields can be dressed up and made more interesting by use of CSS. As of this writing, mainstream browsers don't support CSS styles applied to check boxes, radio buttons, lists, or menus. But text fields, both single- and multiple line, can be given background colors and borders, at least in recent versions of Internet Explorer.

However, Netscape 4.xx browsers can be a challenge to support. The problem is not just that Netscape 4 browsers fail to support these properties; in fact, in some cases they do display them. The real concern is that in some cases the text fields can become nonfunctional, no longer accepting input. Obviously, this is unacceptable.

A workaround used to cope with many of Netscape 4's deficiencies is to use two separate linked style sheets. This workaround is often referred to as "The @Import Trick" due to its use of the @import directive method of style sheet linking.

With this trick, you link one style using the <link> tag; this is a master style sheet, including styles that are widely supported by the major browsers, including Netscape 4. You then link a second style sheet using the @import directive; the second style sheet holds the styles that cause problems in Netscape 4 browsers. Conveniently, Netscape 4 doesn't support the @import directive, and will completely ignore its existence in the document. Internet Explorer and other newer browsers, such as Netscape 6, will see and implement the styles in the @import style sheet, giving them precedence over those in the <link> style sheet, because the @import directive comes later in the code.

The code for linking these two style sheets looks like this:

<link rel="stylesheet" href="master.css" type="text/css">  <style type="text/css">@import url(newbrowsers-only.css);  </style>

Interview: Adrian Senior

Business Name: Webade

URL: http://www.webade.co.uk

How did you get started in web design? What has your learning process been like? What kind of work are you currently doing?

I originally became interested in web design out of curiosity, really. I finally got myself connected and I just wondered, "How do they make those things?" I tend to be a curious person by nature; I have this need to know how things work and that set me off on searches for HTML tutorials. The interest grew from there really; I started with all the tutorials I could find on the web and used Notepad to write them with. Later I came across a demo of HoTMetaL in a magazine; this was my first introduction to WYSIWYG code editors. The program also contained a CSS (Cascading Style Sheet) interface, which was again something completely new to me at that time.

Looking back I'm pleased I had the benefit of not discovering WYSIWYGs straight away. The hand coding gave me a good grounding in what actually goes on behind the scenes. I believe this is a great advantage while designing, as it enables the designer to move back and forth between the design interface and the Code view as necessary. Although the WYSIWYG interface simplifies and speeds up much of the design process, it is often necessary to delve into Code view to make minor corrections or adjustments, so a working knowledge of the required languages is a big advantage.

At this moment in time, much of my work requires database integration; as most of my work is done on Windows servers, the database integration is done with ASP technology; however, there are, of course, other methods you could use. I find data-driven sites are becoming more and more popular; they provide a more interactive experience for the user and allow the web site's content to be manipulated by the client. This allows the site to be truly instant in reflecting the client's business progression; they can just log on to the administration interface we provide for them from anywhere they have an Internet connection. The client is then able to make changes to the information stored in the database; these changes are then reflected immediately on the web site, which dramatically reduces the time required to update the site.

What hardware and software do you use in your work?

I have only ever bought one factory-produced PC and that was the first one I owned. Since moving into web development, I have preferred to build my own machines to the specifications I require. Being an eternal fiddler, I tend to change the hardware on a fairly regular basis with a major overhaul of the machine about every 18 months or so. The last configuration change was a major rebuild to the following specifications:

Processor: AMD Thunderbird 1.2

RAM: 1024MB RAM

Hard drive: 40GB 7200rpm

Operating System: Windows 2000 Pro

Monitor: Dual-monitor setup

Win on CD CDRW

48x CD-ROM

The dual monitors are an important part of the setup for me. I find the ability to work with multiple open programs a great advantage. Much of the software I work with uses the floating panel type of setup; the second monitor is home for these panels, which keeps my work area tidy and uncluttered.

The software I use has changed a fair bit over the years, although I feel happy with what I have at my disposal now. Dreamweaver UltraDev is, I suppose, what you would call my core development tool. It is central to everything I do, the hub that everything else revolves around. For image manipulation, I use Fireworks and Freehand as my main tools, although I always have Adobe Photoshop and Corel Photopaint on hand. Each of these programs provides facilities that I find indispensable. Images often find they make the full trip from Fireworks to Photopaint to Photoshop and back to Fireworks. I just like the way each individual piece of software performs certain tasks, so I use whichever one I think is best for the job at hand. TopStyle is a must-have program. If you're using CSS, and you should be, this has to be number one for creating your style sheets. I couldn't do without it; it just makes it so much easier to manage a site's appearance. Flash is a tool I also find myself using more. When used properly, it can provide a nice addition to any web site.

In working with forms, what techniques are standard for you?

Forms are the web site's heartbeat. They are the means by which we provide interactive communication with the users of our sites, and are, I believe, often underdeveloped. Forms no longer have to be sets of boring white boxes; the power of CSS gives enables us to design forms that blend well with the design of our sites. I use forms for simple communication and data collection from users and also for inserting, updating, and deleting information in databases; this allows easy and quick updates of the web site.

The problem with many of the options available to us is the need to support the Netscape 4 browser. This browser is more than 4 years old and therefore cannot cope with many of the changes that have been implemented in that time; however, it still accounts for somewhere in the region of 10 percent of all Internet users, far too great a number of potential clients to ignore. The poor level of support that Netscape 4 offers on today's Internet does, however, provide us with a workaround that enables us to design forms and our sites in general in such a way that more compliant browsers can render our design as we want.

The workaround involves using two Cascading Style Sheets; this gives us the freedom to design for Netscape 4 without compromising our designs for the more sophisticated browsers.

Other points to take into consideration when designing your forms are the text content and defining its appearance. Both the major browsers render form content differently. So to gain a good standard of equality in your forms appearance on a cross-browser basis, it is advisable to set the text to a monospace font such as Courier or Courier New and to define a specific size for the font. You also have the option to color it to suit your design.

Another aspect I like to include is the personalization and content building that can be built in to a form by requesting form elements from the previous page. Using this method, it is possible to build multipart forms over a series of pages. This provides the user with the option to view previous sections of the form as dynamic data on each page as they complete a more complex form, and we also can provide the ability to return to an earlier form section to correct or change details if necessary. On a similar note, you can request the contents of, say, the first and last names of a person from a completed form and display them dynamically on a thank you page; it's quick and easy to do and provides a personal touch for the user.

When you have had the opportunity to be a little more creative with forms, what have you tried? What would you like to experiment with?

With the release of Netscape 6, and the hopefully in the not too distant future with the release of Mozilla, new support for CSS is going to be available. Although at this moment in time, it is Netscape/Mozilla proprietary, hopefully it will make it through into CSS3. Using the proprietary Mozilla CSS attributes, it makes it possible to apply a radius to your page elements such as form elements and even tables can be manipulated to carry a curved border around their boundaries. I would think it would be some way off before the majority of our viewers can see these effects, but they are available to be used now and experimentation with them is fun and a good learning process.

The following sample code gives form input elements fully rounded ends; you can reduce the radius to give only the corners of the elements a small radius, in effect gently rounding off the sharp edges.

input{ -moz-border-radius: 15px;  background-color : #eaf9ff;  border : 1px solid #000000;  font-family : "Courier New", Courier, monospace;  font-size : 12px;  padding-left : 7px;  padding-right : 7px;  }

As Cascading Style Sheets standards develop, I'm sure we will see the introduction of many new features, features that will provide greater functionality and allow greater freedom of design for the developer.

Although Microsoft and Netscape might make proprietary CSS available to their own browsers, such as the coloring of scrollbars in IE and the radius options among others in Mozilla and Netscape 6. I don't think that's really a problem so long as one doesn't interfere with the other. What we don't need is conflicts of the type we have now with Netscape 4.x.

What trends on the web and in the web designer's work do you see as important?

In a word, standards. With the introduction of XHTML and the improving support for Cascading Style Sheets, I think the Internet is heading in that direction.

The most important aspect of web design, I think, is the planning stage. Getting it right from the outset will save so much time further down the road. From the beginning of any new site I have to develop, I am looking carefully at the maintenance aspect. This area of our work can be so time consuming and fraught with difficulty, especially when returning to the site after a long period of inactivity.

Cascading Style Sheets are possibly the web developer's greatest asset. The ability to update a site's appearance across hundreds of pages utilizing linked styles is really quite remarkable; a simple change of font or color can be completed in seconds.

Dreamweaver itself includes similar features. The utilization of templates in the development of your site and the use of library items both go a long way to simplifying the maintenance of a web site. We can make a single change in a template or a library item and sit back as Dreamweaver propagates those changes through all the child elements.

What advice would you give to someone just starting out in web design?

The best advice I think I could offer to people starting out in web design is don't rely 100 percent on the WYSIWYG view. Buy a good HTML book and learn the code. The benefits of being able to delve into the source and debug are immense if you know what you are looking for, you will save hours of frustration. The best resource for how to design a site is often right in front of you, on the Internet itself. Just download pages and interrogate the code in Dreamweaver. I'm not saying you should reproduce what other authors have done, but look at how they have achieved what you like and learn from them.

Server-Side Scripts for Processing Forms

As discussed earlier in this chapter, forms consist of two components; the purpose here has been to show you how to build an HTML form. A server-side script of some kind is necessary for form data to be processed, but the use and development of these applications is beyond the scope of this chapter.

Note

For more information on using ASP, ASP.NET, ColdFusion, PHP, or JSP with forms, see Chapters 27 through 31.

Many host servers support Perl CGI scripts, and these scripts are easily available, often for free, and can be used to process forms. One well-known script of this type is FormMail, written by programmer Matt Wright. FormMail, when installed and connected with an HTML form, processes the form data and emails the contents to one or more recipients. This script is free, and an excellent tutorial explaining how to install and configure it is available at http://www.appbuild.com/formmail_help.html.

Appendix B, "Online Resources for Dreamweaver Web Developers," includes the URLs of other web sites with information, instructions, and tutorials on installing CGI scripts.

Summary

In this chapter, you learned how forms work to capture data on the web and process it. You also learned the basics of the HTML code used to build forms, and found out how to use Dreamweaver to quickly add forms and form elements to an HTML document. Using behaviors with forms was discussed; you found out how to use the Validate Form behavior and the Set Text of Text Field behavior. You worked through some issues involving the usability and the appearance of forms, and finished with a look at some of the newer form attributes and CSS styling possibilities.

Connecting an HTML form to the application needed to process is obviously crucial; you're encouraged to see this book's chapters on using server-side languages (Chapters 27 through 31) and to look into using the many available Perl CGI scripts and the wealth of information on CGI on the web.

CONTENTS