With a master-detail Web application, typically only a single parameter is used. The parameter uniquely identifies the record selected on the master page and is appended to the link for the detail page. For example, suppose the detail page is details.php, the identifying variable is called tripID, and the specific item is Conquering K2. The full link, with the query string, reads:

details.php?tripID=Conquering%20K2

To create the proper code within Dreamweaver, apply a Go To Detail Page server behavior to the linking text, image, or dynamic data. Master pages also include a Repeat Region server behavior; the Go To Detail Page server behavior is attached to the text or graphic within the region, as shown in Figure 23-1.

Figure 23-1. The Go To Detail Page server behavior within the Repeat Region connects the master page to the proper detail page.

To attach a Go To Detail Page server behavior, follow these steps:

Now that the link is passing parameters successfully, it's time to make sure that the detail page is set up to receive them properly.

Dreamweaver provides two routes for your detail page to use the parameter passed to it by the master page: a filtered recordset or a Dreamweaver server behavior. In general, the first method is less processor-intensive and thus the better choice of the two. The filtered recordset technique returns a recordset of one record—the one used in the detail. If you use the server behavior technique, the entire recordset from the master page is made available, and only the specific record is displayed. You should use the entire recordset method if you want to do recordset paging from one record to the next

Regardless of which technique you use, the detail page should include whatever dynamic data is appropriate. This, of course, requires a recordset. If you're using the server behavior technique, the recordset is generally left unfiltered; in many situations, you can copy the recordset used in the master page and paste it in the detail page using the context-sensitive menus on the Bindings panel. After the recordset is pasted onto the page, you can modify it to include additional fields by double-clicking the recordset entry in the Bindings panel.

Filtering a detail page recordset in Simple mode

You can create the filtered recordset in either the simple Recordset or the advanced Recordset dialog box. To use the simple Recordset dialog, follow these steps:

Note

See Chapter 19 for more on the simple and advanced Recordset dialog boxes.

1. From the Bindings panel, click the Add (+) button and choose Recordset from the list.

2. After you've chosen the name, connection, and table, select the fields required by your details page from the Columns list.

3. From the first Filter list, select the field that coincides with the value passed by the URL parameter, as shown in Figure 23-3. This field should contain unique values that can be used to identify each record.

   

   Figure 23-3. Setting a filter in the simple Recordset dialog box requires completing four fields under the Filter heading.

4. From the second Filter list, select the equals operator (=).

5. From the third Filter list, ASP, .NET, PHP, and ColdFusion users should choose the URL Parameter from the list; JSP users should select the URL/Form Variable.

6. In the fourth Filter field, enter the variable name passed by the master page in the Go To Detail Page server behavior. Avoid names with spaces or other special characters; these names must be URL-encoded and may be difficult to manage.

7. Click OK when you're finished.

You can preview the results of your detail page in Live Data view, but be sure to set up the Live Data settings option first. Choose View

Tip

After entering Live Data view, you can test a variety of different records without reopening the Live Data Settings dialog. In the URL Parameter field found on the Live Data toolbar, change the URL parameter's current value and press Enter (Return). If you enter a value not found in the data source, Dreamweaver displays an error indicating that it cannot display the page.

To test your master-detail application, save both pages and then preview the master page in the browser. When you select the link to the detail page, you should see your chosen record.

WHERE Brand = 'theBrand'

Although Dreamweaver has made crafting master detail Web applications by hand extremely accessible, it can be a tedious series of steps, especially if you have to produce a number of applications for a site. To ease the monotony—and enhance your production efforts—Dreamweaver includes the Master-Detail Page Set application object that, after a single dialog box is completed, creates all the elements for a linked master-detail Web application.

The master page elements are inserted in the current document, which must contain a recordset. The inserted elements and code, shown in Figure 23-5, are as follows:

Figure 23-5. The Master-Detail Page Set application object adds all the designated fields and the required server behaviors to the current page.

The detail page is created when the Master-Detail Page Set Object is executed. As shown in Figure 23-6, the detail page is blank except for a two-column table, which contains a row for each field. The first column displays all the field names in the designated order, and the second column holds Dynamic Text elements, one for each of the fields.

Figure 23-6. Only the fields, data, and necessary server behaviors are included in the newly created detail page.

To create a Web application using the Master-Detail Page Set application object, follow these steps:

The Master-Detail Page Set application object—especially the detail page—works well with Dreamweaver templates. After the master and detail pages are created, you can apply any Dreamweaver template to integrate the results into your site. To prepare the template, just make sure that at least one editable region exists for all the visual elements inserted into the master and detail pages. I say that the Server-Object–generated detail page is especially well suited to template use because the created page contains only the table and its dynamic elements. After applying such a template, as shown in Figure 23-8, you may still need to tweak the design by altering the table properties.

Figure 23-8. Drag a template from the Assets panel onto a detail page to quickly change the look-and-feel of a generated document.

The recordset filter, if it relates to a single form element, can be set in the simple Recordset dialog box. More sophisticated filters, which depend on values received from multiple form elements, must be created in the advanced Recordset dialog box. To set up a form to send user selections to a master page or other Web application, follow these steps:

Now you're ready to implement the receiving portion of your form-value passing application. To do so, follow these steps:

Test your application by saving the master page and previewing the initial page with the form. You can also use View

For more complex recordsets, you have to write the SQL statement in Dreamweaver's advanced Recordset dialog box. The same technique described earlier in the "Filtering a detail page recordset in Advanced mode" section applies here. Declare a variable that uses one of the following runtime values:

The WHERE clause of the SQL sets the fieldname to the variable, as in this example:

WHERE dbadata.Location = theLocation

Multiple form variables can also be set up in the advanced Recordset dialog box. Assume that you want your master page to display a list of employees in a particular department at a specific office. The form might include a drop-down list that displays a number of departments as well as a radio button group for the different offices. If theDept is the variable for the department form list value and theLocation is the variable for the office radio button value, the SQL statement looks like this:

SELECT * FROM Employees WHERE Department = theDept 

AND Location = theLocation

Master-detail Web applications aren't the only applications that can benefit from information entered on a form. Other applications sometimes offer a link to a related page—such as a special note pertinent only to a user-specified selection. To implement such pages, the application page needs the same form information passed to the master page. Dreamweaver includes a Go To Related Page server behavior that delivers the form values to the linked page; the behavior can also pass URL values by themselves or in conjunction with values from forms.

Like other server behaviors in the Go To category, Go To Related Page can be applied to text, images, or dynamic page elements. In a master page with a Repeat Region, you can attach Go To Related Page to an element within the repeating region and have it be available for every entry. To attach a Go To Related Page server behavior, follow these steps:

The Go To Related Page server behavior can also be used to carry results of a form within a series of pages. In other words, if the first Go To Related Page server behavior passed the form or URL values from the master page to the first related page, you can include another Go To Related Page server behavior linked to a second related page.

Text fields are extremely flexible and essential for inputting freeform text into data sources. To create a dynamic text field, follow these steps:

The dynamic data is inserted into what is called the initial value of the form field. You can see the data of the current recordset by selecting View

After you become familiar with Dreamweaver's workings, you can use the Bindings panel to skip most of the previous steps. To use the Bindings panel, follow these steps:

When you attach a checkbox to dynamic data, the checked and unchecked state reflects the true or false state of a Yes/No (also known as a Boolean) type of database field. Not only is this visual method easily understood at a glance, but checkboxes are extremely easy to update. To convert a static checkbox to a dynamic one, follow these steps:

Radio buttons provide a good way to represent a field that has a limited number of options. Suppose your data source includes a Comment Type field, which offers three possible choices: Positive (Pos), Negative (Neg), and Other (Other). To illustrate which type of comment a user submits, your Web application might display a series of three radio buttons, one for each type. If the radio buttons are dynamically tied to the Comment Type field, they show the correct type for each comment. Like checkboxes, radio buttons are very easy to modify—one click and you're done. To link radio buttons to dynamic data, follow these steps:

Typographical errors are the bane of data entry. Regardless of how careful users are, whenever they must enter an exact phrase of any length, typos are inevitable. If the set of desired responses from a user is limited, the list/menu form element provides a good alternative to a text field. An e-commerce site, for instance, might use a list/menu form element (also called a drop-down list or select list) to enable the user to navigate from one product line to another. With Dreamweaver, the drop-down list may be filled (populated) with dynamic data, so that the navigation tool can keep track of the products entered in the data source.

A drop-down list is composed of two parts: the label and the value. The label is what the user sees when he selects the list; the value is what the user submits by selecting a particular list choice. In many situations, both the label and the value may be the same; in these cases, you can use the same data source field for both. Otherwise, you need data source fields available—this is how the product navigation example works. One data source field contains an entry for every product line (the label), and another field contains a URL to that product line's page on the Web site (the value). To link a drop-down list to dynamic data, follow these steps:

You should also notice the new Dynamic button on the Property inspector. Click the button to open the corresponding dialog box. This is another quick way to get to the options without going through the Server Behaviors panel.

To insert records into a data source, you need the following:

No recordset or other data source is necessary, nor are there are any special requirements for the form itself—you don't even have to specify an action or a method. The Insert Record server behavior handles most of the coding chores.

Form elements are typically arranged in a table with labels for each field, as shown in Figure 23-14. Naturally, you can format the table however you like; I generally prefer a two-column table with the labels in the first column, right-aligned, and the form elements in the second column, left-aligned. It's best to name the form elements so that you can identify them easily and ensure that each element is unique. A reset button is optional—but recommended if the form has many fields.

Figure 23-14. You don't need to define a recordset for an insert record page.

After you've constructed your table inside the form and placed the form elements, follow these steps to add the Insert Record server behavior:

With the Record Insertion Form application object, you create a new page and apply the object. Dreamweaver creates the HTML table, includes the form elements and their labels, makes the connection to the data source, and adds the appropriate server-side code. Moreover, this application object is flexible enough to include seven different form element types—Text Field, Text Area, Menu, Hidden Field, CheckBox, Radio Group, and Password Field—as well as Text.

The Menu and Radio Group options are interesting because they enable you to enter the labels and values either manually or dynamically. To take advantage of Dreamweaver's capability to generate dynamic menus and radio buttons, you must have a recordset or other data source on the page. To insert the Record Insertion Form application object, follow these steps:

In the day-to-day operations of most Web sites, you update records more often than you insert new records. The process in Dreamweaver for creating an update records page is similar to the one for the insert records application with one important difference—you must have a recordset defined. Detail pages are good candidates to transform into update applications. They already have the features necessary for an update application; namely, they have a recordset or other method for specifying a single record, and they are often generated from master-type pages. The major difference is that an update records application also requires specific server-side code—which is supplied in Dreamweaver by the Update Record server behavior.

As with the insert record application, you can choose to either create all the components of an update record page yourself or use the application object to build them for you. To prepare the page for adding the Update Record server behavior, make sure you include a form element for every data field you want to update as well as a Submit button. Neither the action nor method attributes of the form need to be set—the Update Record server behavior handles that chore. To insert an Update Record server behavior, follow these steps:

If you'd prefer Dreamweaver to set up the form elements for you, use the Record Update Form application object. Before you can insert this application object, you must define a recordset or other data source from which to extract the data. The advantage of using Dreamweaver is sheer speed. Instead of manually creating the form, let Dreamweaver do the grunt work for you. To create an update record application using the application object, follow these steps:

When these steps are completed, Dreamweaver inserts a borderless two-column table with the requested form elements and labels, similar to the one shown in Figure 23-17. As with other application objects, you can easily apply a template and include the generated elements in an editable region.

Figure 23-17. The Record Update Form application object creates all the elements and code necessary for modifying data source records online.

Eliminating outdated or otherwise unneeded records is a key task in properly maintaining a data source. The Delete Record server behavior greatly simplifies the chore. All that the Delete Record server behavior requires is a recordset and a form with a Submit button.

To attach a Delete Record server behavior to a form, follow these steps:

The Delete Record server behavior is executed when the user clicks the Submit button in the form. It's a good idea to confirm the deletion with your user on the destination page.

Both application and session variables are used throughout Web applications. An application variable is one that continues to exist as long as the application is active; in this situation, the application is the Web site itself. Application variables are available to all users of a site. A hit counter often uses an application variable to track the number of visitors to a site.

Although all users can see the results of a calculation involving application variables, session variables are user-specific. A session starts when a user first visits a site and ends shortly after the user leaves. Session variables are often used for user authentication and to maintain information about users as they travel through the site; shopping carts often employ session variables. Both application and session variables are available in ASP, PHP, and ColdFusion; in JSP only session variables can be inserted through the Bindings panel; .NET doesn't allow any declared variables.

Each of the server models, with the exception of .NET, has a range of variables available aside from application and server variables. All are accessible through the Add (+) button of the Bindings panel and all, except for ASP Request variables, use a one-field dialog box for the name of the variable. In the case of the ASP Request variables, all five types of variables are available through a drop-down list on the Request Variable dialog box. After you've chosen your variable, enter its name in the Name field. Table 23-1 provides a breakdown of the available variables for each of the Dreamweaver server models.

Creating the Results Page

To complete the search application begun in the previous Technique, you need to create a results page. Unlike the search page, the results page contains server-side code easily inserted through Dreamweaver.

1. From the 22_Dynamic_Pages folder in the Techniques - Dynamic site, open the results_start file for your server model.

   To save time, a table to hold your search results has already been added to the page. The first task is to add a recordset to the page.

2. From the Bindings panel, click Add (+) and select Recordset (Query) from the list.

3. In the Recordset dialog box's Simple mode, enter rsResults in the Name field.

4. From the Connection list, choose RelativeRealty.

5. From the Table list, select Properties.

   To return the proper results for the search, you need to limit the recordset to records in which the database's description field contains the keyword searched for. You'll recall that text field in the search page was named searchField.

6. Set the Filter options like this:

   propDesc	contains
   Form Variable	searchField

   

7. Leave the Sort list at its default setting and click OK.

   With the recordset defined, you're ready to begin binding data to the page.

8. In the Bindings panel, expand the Recordset (rsResults) entry.

9. Place the proper dynamic data in position:

   • Drag propType to the cell under the Type label.

   • Drag propDesc to the cell under the Description label.

   • Drag propBedrooms to the cell under the Bedrooms label.

   • Drag propBathrooms to the cell under the Bathrooms label.

   • Drag propAgent to the cell under the Agent label.

10. Select any of the dynamic elements just added to the page like rsResults.propType and, from the Tag Selector, choose the <tr> tag.

11. From the Server Behaviors panel, click Add (+) and select Repeat Region from the list.

12. In the Repeat Region server behavior, make sure that rsResults is the chosen recordset and set the option Show All Records; click OK when you're ready.

13. Save your page.

14. In the Files panel, select both the pages of the search application—search_start and results_start—for your server model and choose Put to publish the files to the Testing server.

To test your search application, preview the previously built search_start page in a browser. Enter a keyword, such as "kitchen," in the text field and click Search; the results page will display any matching entries.

The most common way to identify returning customers is to allow them to log in. A login page can be as simple as a three-element form: two text fields—one for the username and one for the password—and a Submit button. The form connects to a data source containing a list of users and their passwords, among other information, and verifies that the submitted username corresponds with the submitted password. Dreamweaver accomplishes this task with the appropriately named Log In User server behavior.

The Log In User server behavior redirects authorized users to one page and unauthorized users to another. In addition, it creates a session variable containing the username. This session variable can then be employed on other pages as required.

To apply the Log In User server behavior, make sure your page has, at a minimum, a form with text fields for the username and password, and a Submit button. You're now ready to follow these steps:

Now that you've got your users added and logging in, you need to protect those pages that require authorized access. These could be their user profile information or perhaps information they've paid a subscription to access. Dreamweaver provides two different types of access restriction. The first method just determines if a user is logged in or not. The second includes restriction based on access levels defined in your database.

To restrict access based on whether a user has logged in or not, follow these steps:

To restrict pages based on access level, add a login page as shown in Figure 23-21. This is handy if you want to have one login for both your administrators and your regular customers. One access level may be able to change user details, whereas another can only view those details. In step 12 of creating the login form in the previous section, choose the Restrict Access Based On Username, Password, and Access Level option. Next, choose the field from your table that contains the access levels, as shown in Figure 23-22.

Figure 23-22. Use the Get Level From list menu in the Log In User dialog to restrict access to a page to a specific group of users. This gives you more granular control over your site.

To restrict access based on access levels, follow these steps:

It's always a good idea to give your customer an easy way to log out of your site—a way that also destroys all the session variables associated with his login and ensures that his coworkers can't jump on his computer (right after he leaves for some coffee) and gain access to information they shouldn't have. Logging out a user in Dreamweaver is just a matter of one simple server behavior.

To use the Log Out User server behavior, follow these steps:

An application that adds new customers is essentially the same as an insert record application, with one additional function. If you've ever tried to get a username on America Online that even remotely resembles your own name, chances are you've encountered the function I'm talking about—just ask bobsmith01234x. For a username to be useful, it must be unique; therefore, the Web application must check a submitted username for uniqueness. Dreamweaver's Check New Username server behavior does just this.

Before you can apply the Check New Username server behavior, however, you must create a page with the proper form elements for all the data necessary. Moreover, you need a Dreamweaver Insert Record server behavior (refer to Figure 23-15 earlier in this chapter). As the name implies, the Insert Record server behavior creates a new record and adds it to the specified data source.

The one difference between a standard Insert Record server behavior and the one used in this circumstance is that you leave the destination page field (After Inserting, Go To) blank. Leaving this field empty enables the Check New Username server behavior to control the redirection.

The Check New Username server behavior verifies that the requested username is not already in the data source and redirects the user if it is. To add a Check New Username server behavior to your page, follow these steps: