Dreamweaver MX 2004 Bible phần 7 doc

694
Part IV ✦ Incorporating Dynamic Data
Figure 20-5: Use Dreamweaver’s Show Region server behavior to display or hide
navigation buttons depending on the dynamic data shown.
To apply a Show Region server behavior, follow these steps:
1. Select the page area you would like to conditionally show.
2. From the Server Behaviors panel, choose Add and select one of the server behaviors
from the Show Record submenu. The dialog box for the specific Show Record server
behavior you chose is displayed, like the one shown in Figure 20-6. The dialog boxes for
all the Show Record server behaviors are identical.
3. From the Recordset list, select the recordset on which to base the Show Record
condition.
4. Click OK when you’re done.
Typically, the Show Region server behaviors are used in pairs. Apply a Show Region If Not
First Record server behavior to a Previous Record link — it hides the link when the user is on
the first record. Similarly, apply a Show Region If Not Last Record server behavior to the Next
Record link to cause the link to disappear when the last record is called.
Only the first two Show Region server behaviors —Show Region If Recordset Is Empty and
Show Region If Recordset Is Not Empty—may be applied to a page without any precondi-
tions. The other four Show Region server behaviors require that one other type of server
behavior be present on the page: the Recordset Paging server behavior. The Recordset
Paging server behaviors act like VCR controls, adding a link that, when selected, displays the
first, last, next, or previous set of records. The Recordset Paging server behaviors are cov-
ered in more detail in the following section.
543504 ch20.qxd 12/10/03 10:33 PM Page 694
695
Chapter 20 ✦ Managing Data
Figure 20-6: To use a Show Record server behavior, all you do is choose a recordset.
Handling Record Navigation
So far in this chapter, you’ve seen how to repeat dynamic data and how to hide and display
data and other page elements programmatically. Now it’s time to put some real interactive

controls into the hands of your Web application users. Dreamweaver includes a set of server
behaviors that enable the user to page through your recordset, much as if they were flipping
the pages of a catalog.
You can approach Dreamweaver’s record navigation through two avenues: One option is a do-
it-yourself route, or you can let Dreamweaver do most of the work for you. To better under-
stand how record navigation works, examine the piece-by-piece approach first.
Building record navigation links
As mentioned in the previous section on Show Region server behaviors, Dreamweaver also
includes a set of server behaviors to control navigation within a recordset. Again, the applica-
tion is straightforward: Select the text or image you’d like to serve as a trigger and attach the
appropriate server behavior. When selected, the trigger fires the server-side code that
retrieves the chosen record. If a Repeat Region is inserted on the page, the next or previous
group of records is displayed.
543504 ch20.qxd 12/10/03 10:33 PM Page 695
696
Part IV ✦ Incorporating Dynamic Data
You can find five server behaviors under the Recordset Paging submenu:
✦ Move To First Record
✦ Move To Previous Record
✦ Move To Next Record
✦ Move To Last Record
✦ Move To Specific Record
The final Recordset Paging server behavior, Move To Specific Record, is most often used in
conjunction with a search routine or a master-detail application.
As noted, you can use either text or images as your controls. Navigation links, such as those
shown in Figure 20-7, may even include rollovers or other client-side behaviors. You can even
use Flash buttons to trigger recordset navigation; see “Dreamweaver Technique: Using Flash
Buttons for Recordset Navigation” later in this chapter, for a detailed explanation of how it’s
done.
You don’t need to add an initial or placeholder link to your image or text. When the

Recordset Paging server behavior is applied, the link is written for you.
Figure 20-7: You can use images —with or without rollovers— to navigate through a
recordset with Dreamweaver’s Recordset Paging server behaviors.
Tip
Note
543504 ch20.qxd 12/10/03 10:33 PM Page 696
697
Chapter 20 ✦ Managing Data
To create recordset navigation links, follow these steps:
1. Select the text or image to which you’d like to attach the server behavior.
2. From the Server Behaviors panel, select Add. Choose the desired behavior from the
Recordset Paging submenu. The appropriate Recordset Paging dialog box appears. If
you’ve made a selection, it’s highlighted in the Link list; otherwise, a new text link is
created, as shown in Figure 20-8.
3. Make sure that the selection in the Link list is the link you want.
4. Choose the recordset you want to work with from the Recordset drop-down list.
Figure 20-8: The Recordset Paging server
behaviors identify your selected target,
whether it is an image or text.
5. Click OK when you’re finished.
6. Repeat Steps 1 through 5 to add more recordset navigation elements.
Record navigation is done within a particular recordset; you can’t link from one recordset to
another using the Dreamweaver server behaviors or Application objects.
After you’ve added your navigation controls, you may want to take the next step toward a
more complete user interface by adding Show Region server behaviors to ensure that the
controls are displayed only when they serve a purpose. For example, if you have a navigation
element that moves to the last record of a recordset, you probably want to attach a Show If
Not Last Record server behavior to the trigger.
Using Application objects for record navigation
Although the process for setting up a single navigation control is fairly simple, you’d have to

perform that process four times (as well as attach four additional server behaviors) to
accomplish what the Recordset Navigation bar does in one operation. The Recordset
Navigation bar is one of Dreamweaver’s Application objects —one that can take the drudgery
out of a repetitious implementation. All the Application objects are accessible through either
the Insert ➪ Application Objects menu or the Application tab in the Insert bar.
The Recordset Navigation Bar Application object serves the following multiple purposes:
✦ Adds four links to the page in a borderless, single-row table: First, Previous, Next, and
Last. The links may be either text or graphics.
✦ Attaches the appropriate Recordset Paging server behavior to the four links.
Note
543504 ch20.qxd 12/10/03 10:33 PM Page 697
698
Part IV ✦ Incorporating Dynamic Data
✦ Inserts a Show Region server behavior to each of the links:
• Show If Not First Record is added to the First and Previous record links.
• Show If Not Last Record is added to the Next and Last record links.
✦ Centers the table on the page and sets the width to 50%.
What’s even more impressive about this list of functions is that they are implemented with a
single command, which, in turn, references a very simple dialog box, as shown in Figure 20-9.
Here’s how it works:
1. Choose Insert ➪ Application Objects➪ Recordset Navigation Bar or choose Insert
Recordset Navigation Bar from the Application category of the Insert bar. The
Recordset Navigation Bar dialog box is displayed.
2. Select the data you want to control from the Recordset list.
3. To create a series of text links, choose the Display Using Text option.
4. To use graphics to trigger the navigation, choose the Display Using Images option.
You must save the page if you select the Display Using Images option. Dreamweaver copies
images from the Shared/Dreamweaver/Images folder when you choose this option, and the
page into which they are being inserted must be saved in order to store the images properly
in the site. They are stored in the same folder as the page containing them.

Figure 20-9: The Recordset Navigation Bar
dialog box offers a choice between text links
or graphics.
After the Recordset Navigation bar has been inserted, you can adjust the text or images in
any way you see fit. The text may be styled or modified, and you can even swap out the
images —by changing the
src attribute —for another graphic.
Tracking record status
Another Application object inserts the text and all the server behaviors necessary to display
the records currently being viewed. By default, the syntax used by the Recordset Navigation
Status Application object is as follows:
Records First_Record_Shown to Last_Record_Shown of Total_Records
This syntax works perfectly for Web applications that use a Repeat Region server behavior to
show multiple records. When viewed through the browser, the Recordset Navigation Status
output looks like the following:
Records 5 to 10 of 37
Caution
543504 ch20.qxd 12/10/03 10:33 PM Page 698
699
Chapter 20 ✦ Managing Data
If you’re displaying one record at a time, you can adjust the Application object code inserted
so that it is similar to the following:
Record First_Record_Shown of Total_Records
Like the Recordset Navigation bar, this Application object works with only one recordset at a
time. The Recordset Navigation Status Application object works similarly, as shown in the fol-
lowing steps:
1. Choose Insert ➪ Application Objects➪ Recordset Navigation or click the Recordset
Navigation Status icon on the Application category of the Insert bar. The Recordset
Navigation Status dialog box is displayed, as shown in Figure 20-10.
Figure 20-10: The Recordset Navigation Status

Application object inserts three different server
behaviors in one operation.
2. Select the data you want to control from the Recordset list.
3. Click OK when you’re finished.
Dreamweaver Technique: Using Flash
Buttons for Recordset Navigation
Flash buttons are an excellent Dreamweaver tool for adding lively navigation aids to your
Web page, but they’re intended for page-to-page linking, not recordset navigation. However,
with a little additional work, you can adapt standard or custom Flash buttons to control
Dreamweaver’s Recordset Paging server behaviors.
Flash buttons are actually Macromedia Generator Templates that when processed by
Dreamweaver become Flash movies. As a Generator Template, the link information is com-
piled into the Flash movie and is not accessible for server-side processing —a necessity for
moving from one record to another. Enabling Flash buttons to control recordset navigation
requires four main components:
✦ Server-side code for moving from record to record
✦ A JavaScript call from the Flash button
✦ A JavaScript function in the
<head> of the document
✦ A hidden field variable in a form
The first requirement is actually the easiest, as the necessary server-side code is provided by
Dreamweaver.
543504 ch20.qxd 12/10/03 10:33 PM Page 699
700
Part IV ✦ Incorporating Dynamic Data
Step 1: Prepare the page
Before you can begin the specific steps for converting the Flash buttons for your use, some
preliminary work needs to be done. First, make sure that you have added your recordset and
any necessary fields. You can always add more fields from the Bindings panel later, but it’s
good to have one or two in the page to test the navigation buttons.

Next, add the server-side code. You can accomplish this in one of two ways: Either enter
some text and attach a Recordset Paging server behavior to it, or use Dreamweaver’s
Recordset Navigation bar from the Insert ➪ Application Object menu. To save time — and
because you’ll likely be adding multiple controls—choose the Application object route by
choosing Insert ➪ Application Object➪ Recordset Navigation Bar. If you follow this path,
choose the Display Using Text option rather than images. Later, when you delete the links
(but not the code), you’ll have extraneous files in your local site if you opt for graphics now.
One final bit of prep work before you add the Flash buttons: Add a form to your page if one is
not already present. If you like, give it a unique name; one convention you might try is to
identify the forms on your pages with the name
theForm. The form may enclose the other ele-
ments, as shown in Figure 20-11, or be separate.
Figure 20-11: To prepare for the Flash Recordset Navigation buttons add a form and
Dreamweaver’s standard Recordset Navigation bar.
543504 ch20.qxd 12/10/03 10:33 PM Page 700
701
Chapter 20 ✦ Managing Data
Step 2: Add the Flash buttons
Now you’re ready to insert your Flash buttons. Note one small difference between the regular
Flash buttons and the ones used in the Dreamweaver technique. In your version, you call a
JavaScript function rather than link to another page.
If you’re not familiar with Flash buttons, be sure to look over Chapter 24 to understand their
basic usage and learn how you can create your own custom Flash buttons with Flash MX.
To insert your modified Flash button, follow these steps:
If you’re already familiar with Flash buttons, skip to Step 7.
1. Make sure that the current document has been saved. If you’re working on a new docu-
ment, Dreamweaver requires that you save it before adding a Flash button.
2. Choose Insert ➪ Media➪ Flash button. The Insert Flash Button dialog box, shown in
Figure 20-12, is displayed.
Figure 20-12: Instead of a relative URL, put a call to a

JavaScript function in the Link field of your Flash button.
3. Select a button type from the Style list. The previews shown in the Sample area are live
demonstrations and play as designed when moused-over or clicked. Note, however,
one exception: No sounds are played in preview; you have to preview the Flash button
in the browser to get the full effect.
4. If appropriate, enter custom text in the Button Text field. The Button Text field is physi-
cally limited to 50 characters, although probably your text will be shorter. Certain sym-
bols, such as those in the Control group, ignore the text and font settings.
Note
Cross-
Reference
543504 ch20.qxd 12/10/03 10:33 PM Page 701
702
Part IV ✦ Incorporating Dynamic Data
5. Select a typeface from the Font drop-down list if appropriate. The fonts listed are
TrueType fonts found on your system. Most of the button templates have a preselected
font and text size. If you do not have the preselected font on your system, a small alert
appears at the bottom of the dialog box.
6. Enter the desired font size if appropriate, in points, in the Size field.
7. Enter a JavaScript call to a function that sets the recordset navigation in the Link field.
For our example, you can use the functions
moveNext(), movePrev(), moveFirst(),
and
moveLast(). For a button that moves to the next record, the entry into the Link
field reads as follows:
javascript:moveNext();
8. Leave the Target field blank.
9. If the Flash button is to be placed on a page or in a table with a background color other
than white, select the Bg Color swatch to choose an appropriate background.
Alternatively, enter the hexadecimal color number or standard color name directly in

the Bg Color text field.
10. Enter a path and filename for the Flash button file. If you like, you can use the sug-
gested default name in the site root, or select the Browse button to choose a different
location.
11. Choose Apply to insert the button at the cursor location on the page.
12. Click OK when you’re finished.
The JavaScript function names listed in the steps here may be changed to whatever you like.
However, be sure to use the same names as the actual functions when you insert them in the
code, as described in the next step.
Step 3: Include the JavaScript functions
Now it’s time to include the functions referenced in the Flash Button Link field. As JavaScript
functions go, these are as simple as they get—with just one line of code each. When exe-
cuted, each of the JavaScript functions does the same thing: It sets the current URL to a value
specified in a hidden form variable. You set the form variables in the next step.
Although there are four variations — one for each type of recordset navigation—the basic
function looks like the following:
function moveNext() {
document.location.href=document.theForm.nextHidden.value
}
The function name —here, moveNext() —is arbitrary, but note that it matches the function
name specified in the Flash button setup. The reference to the hidden form variable is also
specific to this code —again, you can name the variables whatever you like; just ensure that
the names match the code in the function.
This code uses the following four functions:
function moveNext() {
document.location.href=document.theForm.nextHidden.value
}
543504 ch20.qxd 12/10/03 10:33 PM Page 702
703
Chapter 20 ✦ Managing Data

function movePrev() {
document.location.href=document.theForm.prevHidden.value
}
function moveFirst() {
document.location.href=document.theForm.firstHidden.value
}
function moveLast() {
document.location.href=document.theForm.lastHidden.value
}
If you’re totally unfamiliar with writing JavaScript, you can use Dreamweaver’s Script object
to insert the code. However, make sure that the code goes in the
<head> section of the docu-
ment. Use the following steps to accomplish that:
1. Choose View➪Head Content to expose the
<head> region in Dreamweaver’s Document
window.
2. Choose Insert ➪ HTML➪ Script Objects ➪ Script. Alternatively, you could select the
Script icon from the HTML category of the Insert bar. The Script dialog box, shown in
Figure 20-13, is displayed.
Figure 20-13: If you are new to JavaScript, use
Dreamweaver’s Script object for inserting code.
3. Select JavaScript from the Language list.
4. Enter the desired functions into the Content text area. You can enter as many of the
functions as you’d like, or all of them.
5. Click OK when you’re finished.
If you’re more familiar with JavaScript, you can enter the functions directly through
Dreamweaver’s Code view. The functions may be inserted into an existing
<script> . . .
</script> tag pair, or you can create your own. Now you’re ready to add the final piece of
the basic puzzle: the hidden variables.

543504 ch20.qxd 12/10/03 10:33 PM Page 703
704
Part IV ✦ Incorporating Dynamic Data
Step 4: Insert the hidden variables
Everything you’ve done to this point could also be done in a static Web page; but it’s time to
add the server-side component. Whenever a Recordset Paging server behavior is applied,
whether manually or automatically by inserting an Application object, Dreamweaver writes a
bit of server-side code in the
href attribute of the <a> tag surrounding the trigger element. It
is this code that you must make accessible in order for the Flash button to work properly as a
recordset navigation tool.
The server-side code varies from server model to server model but, in essence, it’s quite sim-
ilar. Here, for example, is the code inserted when a Move To Next Record server behavior is
applied:
ASP
<%=MM_moveNext%>
ColdFusion
<cfoutput>#CurrentPage#?PageNum_rsEmployees=#Min(IncrementValue(Page
Num_rsEmployees),TotalPages_rsEmployees)##QueryString_rsEmployees#
</cfoutput>
JSP
<%=MM_moveNext%>
.NET
<%# Request.ServerVariables(“SCRIPT_NAME”) %>?rs_currentPage=<%#
rs.CurrentPage + 1 %>
To keep this code accessible for server-side processing —and viable for the JavaScript func-
tion to use —it must be embedded in a hidden variable form element. After the code is trans-
ferred, the temporary recordset navigation elements previously inserted can be deleted.
Here’s how to accomplish this task, step by step:
1. Select the text link that matches the recordset navigation intended for your Flash button.

You can start anywhere because you’re eventually going to add Flash buttons for all
your recordset navigation moves.
2. From the Property inspector, select and copy the value of the
href attribute using the
keyboard shortcut Ctrl+C (Command+C) or the context menu.
3. Position your cursor anywhere in the form and choose Insert ➪ Form ➪ Hidden Field or
select the Hidden Field icon from the Forms category of the Insert bar.
It doesn’t matter where the Hidden Field object is placed, as long as it’s within the
<form> tag.
4. In the Hidden Field Property inspector, change the name from the default
hiddenField
to a unique name. This name must be the same as the one used in the JavaScript func-
tion. You might want to create a name for form elements by first describing what the
element relates to, followed by the type of form element. For example, the four hidden
fields used in recordset navigation are called
firstHidden, lastHidden, nextHidden,
and
prevHidden.
5. In the Value field of the Property inspector, paste the copied code as shown in
Figure 20-14.
543504 ch20.qxd 12/10/03 10:33 PM Page 704
705
Chapter 20 ✦ Managing Data
Figure 20-14: The Hidden Field form element acts a conduit to
the JavaScript function, passing the processed server-side value,
which, in turn, is called by the Flash button.
6. Repeat Steps 1 through 5 for every Flash button recordset control intended for the page.
7. After you’ve added all the hidden fields needed, you’re free to delete the temporary
recordset navigation text links. Dreamweaver alerts you that not all the server behav-
iors have been deleted; you can safely ignore this warning. The part left behind is

exactly what you’ll use.
Your Flash button is now recordset-navigation ready. Test your page by using Dreamweaver’s
Preview in Browser feature.
Remember: If the folder for your testing server is on a different machine or in a different loca-
tion from your local site root, you must transfer all the dependent files —including the SWF
files used by the Flash buttons —before the Flash buttons work correctly.
To make the Flash button interface as intuitive as possible, add Show Region server behav-
iors to the various buttons, as detailed in the “Showing and hiding page elements” section
earlier in this chapter and shown in Figure 20-15.
Figure 20-15: The Flash buttons appear only when they are useful, courtesy of
Dreamweaver’s Show Region server behaviors.
Tip
543504 ch20.qxd 12/10/03 10:33 PM Page 705
706
Part IV ✦ Incorporating Dynamic Data
Summary
In order to be part of an effective Web application, dynamic data can’t just be displayed; it
has to be designed. Dreamweaver, through a variety of server behaviors, gives you the power
to selectively repeat page elements as well as show them programmatically. Data design is an
important aspect of integrating the server side with the client side. As you look for ways to
manage the data in your Web applications more effectively, remember the following points:
✦ With the aid of the Repeat Region server behavior, Dreamweaver can help you to show
as much of the data on a single page as you desire. Repeat Region server behaviors are
usually applied to table rows, but they may also be used with line-breaks, paragraphs,
list items, or any other HTML element.
✦ It’s often necessary to show data only if a certain condition is met. Dreamweaver han-
dles these operations through a variety of Show Region server behaviors. With these
tools, you can also selectively display any element —text, graphic, or dynamic data —
on the current page.
✦ After you have the capability to display a portion of your data, you must navigate the

recordset. Dreamweaver’s Recordset Paging server behaviors can show the next or pre-
vious record (or group of records, if the Repeat Region server behavior is used), as well
as quickly navigate to the first or last record of your data.
✦ Recordset navigation can be integrated in several ways. You can add each building
block (the graphics or the text, the server behaviors, and so on) by itself, or you can
accomplish the same task in one operation by using a Dreamweaver Application object.
Depending on the Web application, you might find it quicker to insert and modify the
Recordset Navigation Bar Application object, rather than build your own step-by-step.
✦ You can convert Flash buttons to act as recordset navigation aids. The step-by-step
Dreamweaver Technique details the necessary modifications.
In the next chapter, you learn how you can use Dreamweaver’s Live Data view to enhance
your workflow and test your application under a variety of circumstances.
✦✦✦
543504 ch20.qxd 12/10/03 10:33 PM Page 706
Working with
Live Data
W
hen I first started with print and design layout, I would drive
all over the city to finish a job. After receiving the client’s
go-ahead, I had to pick my type from a phototypesetter and my images
from a stat house. Then, back at my studio, I’d cut and paste—and I
mean literally, with scissors and glue —the text and images into place,
hoping against hope that I had specified the type and image sizes cor-
rectly. If not, it was back in the car for another trip or two around
town. Ah, the good old days.
Now designers (especially those who design for the Web) have the
luxury of developing their creations right in their own studio. Until
Dreamweaver, however, the development of a Web application often
undertook a faster, albeit parallel, course to my inner-city travels.
After a basic page was designed, complete with server-side code, the

document had to be uploaded to a testing server and then viewed in
a browser over the Internet. If—make that when —changes were
needed, the pages were revamped back in the studio. Because the
designer was not able to lay out the page with the actual data in place,
modifications were a trial-and-error process that often required many,
many trips to the server and back.
Dreamweaver’s Live Data view eliminates the tedium and the lengthy
time required for the upload-preview-modify-upload cycle. With Live
Data view, developers work with the layout while the actual data is
live on the page. If a table width needs to be adjusted because one of
the records is too long, you can make the change immediately with
no guesswork. Live Data view processes the page in the chosen server
model. If the page requires variables, such as search criteria, in order
to run properly, the Live Data feature enables you to set such values
as needed. Although a preliminary discussion of Live Data is covered
in Chapter 19, this chapter covers all the necessary details for using
both basic and advanced Live Data capabilities.
Although Live Data is a terrific timesaving feature, you can’t rely on it
totally for testing your Web application. You still need to preview the
page in various browsers to ensure cross-browser compatibility. The
final section of this chapter is dedicated to Dreamweaver’s Preview in
Browser feature and its relationship to your testing server.
21
21
CHAPTER
✦✦✦✦
In This Chapter
Understanding the Live
Data process
Designing in Live Data

view
Testing different variable
values
Previewing with a
testing server
✦✦✦✦
543504 ch21.qxd 12/10/03 10:37 PM Page 707
708
Part IV ✦ Incorporating Dynamic Data
Viewing Live Data
After your site is properly set up, entering Live Data view is just a click away. Click the Show
Live Data View button on the toolbar to refresh Dreamweaver’s Document window and to
replace all the dynamic data placeholders with information from the declared data source.
With Invisible Elements enabled (the default for Dreamweaver), the newly visible Live Data
is highlighted in whatever color is specified in Preferences.
In order to get the most out of Live Data view— and to avoid problems—you need a firm
grasp of how Dreamweaver is able to present your data, live. The following sections can help
you understand this timesaving feature.
How Live Data works
Once you’ve entered Live Data view, you may notice an animation of a spinning Dreamweaver
logo in the right-hand corner of the Live Data toolbar before the page is refreshed. When the
animation stops, Dreamweaver has all the information needed to present the completed page.
Here is what’s really happening behind that spinning lowercase d:
1. The developer inserts dynamic data elements into a standard HTML page. The dynamic
data is represented by placeholders that combine the recordset and field names in a
set of curly braces, like
{rsEmployees.FirstName}.
2. When the Live Data view is enabled, Dreamweaver creates a hidden, temporary copy of
the current page.
3. The temporary page is then stored in the folder designated in the Testing Server cate-

gory of the Site Definition dialog box.
4. Dreamweaver instructs the defined testing server to execute the server-side code
within the page and passes along any variables that have been specified. The URL pre-
fix designated in the Site Definition Testing Server category is used to invoke the page.
5. When the code is executed, Dreamweaver reads the resulting HTML code.
6. Finally, Dreamweaver uses its translator capability to substitute the dynamic data
placeholders shown in the original document with the data generated. The temporary
document is deleted from the server.
If all goes well, a page with dynamic data placeholders (shown in Figure 21-1) is replaced with
the Live Data view (shown in Figure 21-2).
If Dreamweaver encounters an error, it displays a message that explains where the process
failed and suggests some possible remedies.
Setting up for Live Data
As noted in the summary of how Live Data works, several values found in the Testing Server
category of the Site Definition dialog are key to this feature’s operation. Live Data must know
the location of the site root for the temporary page and how that location may be reached
with an HTTP request. If either of these values is not found, the attempt to switch to Live
Data view is aborted and an error message appears.
543504 ch21.qxd 12/10/03 10:37 PM Page 708
709
Chapter 21 ✦ Working with Live Data
Figure 21-1: This table contains a row with four dynamic data fields, surrounded by a
Repeat Region server behavior.
There are two different methods for accessing the testing server: locally, through a network,
or remotely via FTP. If the testing server is to be accessed locally, the location of the folder
storing the pages is entered in the Testing server folder field, shown in Figure 21-3. Although
it is referred to as the Testing server folder, if you’re using a local Web server such as Internet
Information Services (IIS) on your local testing machine, this entry is likely to be the same as
your Local Root Folder, as defined in the Local Info category of the Site Definition dialog box.
The other field essential to proper Live Data operation is the URL Prefix field. When Live Data

sends the HTTP request to the testing server, the address contained in this field prefaces the
name of the temporary page. For example, if my temporary page is named
TMPGX123455.asp
and the URL prefix is http://localhost/dba, the URL used is
http://localhost/dba/TMPGX123455.asp.
Localhost is common shorthand for addressing a local Web server; generally, you can also
use the Internet Protocol (IP) address 127.0.0.1.
Initially, Dreamweaver inserts only the http://localhost/ address into the URL Prefix
field. This works if your local site root corresponds to the local Web server root. However,
if your site root is in a different directory, you have to fill in the path of that directory. Most
Web servers permit the creation of virtual directories, which are aliases recognized by the Web
server. If you’re using Windows 2000 or Windows XP Professional, then you may already have
Internet Information Services (IIS) available, and you can set up your own virtual directories.
Tip
543504 ch21.qxd 12/10/03 10:37 PM Page 709
710
Part IV ✦ Incorporating Dynamic Data
1. First, check to see if you have IIS by right-clicking My Computer on your desktop
and choosing Manage. In the Computer Management console, expand Services and
Applications. If you see Internet Information Services listed, then you’ve got everything
you need installed and you can skip to Step 2. If you don’t see IIS listed, choose Start ➪
Control Panel, double-click Add/Remove Programs and choose Add/Remove Windows
Components. Check Internet Information Services in the Windows Component Wizard
and follow the dialogs to install IIS.
2. Right-click the Default Web Site and choose New ➪ Virtual Directory, as shown in Figure
21-4. This action opens the Virtual Directory Creation Wizard. Click Next to get started.
3. On the Virtual Directory Alias screen, enter the alias for the folder. This will be appended
to the end of the
http://localhost/ address. If you name your virtual directory
“dba” then the URL would be

http://localhost/dba. Click Next to continue.
4. On the Web Site Content Directory screen, browse to the folder that contains your site
and click Next.
5. Click Next on the Access Properties screen to continue, and click Finish on the next
screen to add the virtual directory.
Figure 21-2: After Live Data view is enabled, the full number of records allowed by the
Repeat Region is displayed and provides an accurate representation of the data.
543504 ch21.qxd 12/10/03 10:37 PM Page 710
711
Chapter 21 ✦ Working with Live Data
Figure 21-3: Enter the location of your local files and a locally
established site in the URL Prefix field to enable Live Data view
to find your application.
ColdFusion MX developers with a local testing server need to specify the port number if
ColdFusion is installed as a stand-alone server. By default, ColdFusion MX uses 8500, which
results in a URL Prefix of http://localhost:8500/.
If you’re connecting to a remote testing server, choose FTP from the Access list on the Testing
Server category of the Site Definition dialog box. When FTP is selected, Dreamweaver displays
the same information entered under the FTP heading in the Remote Info category. Additionally,
Dreamweaver combines the entries under FTP Host and Host Directory in the URL prefix with
an initial
http://. For example, if your entry under FTP Host is www.drinkgoodstuff.com
and Host Directory is blank, the URL prefix reads />You may have to edit your URL prefix if your FTP host uses an ftp prefix. If my host directory
were ftp.drinkgoodstuff.com, Dreamweaver would create the URL prefix entry
, an unworkable URL. Here, the ftp must be changed
to www.
Caution
Note
543504 ch21.qxd 12/10/03 10:37 PM Page 711
712

Part IV ✦ Incorporating Dynamic Data
Figure 21-4: Right-click the Default Web Site in IIS and choose New ➪ Virtual Directory
to open the Virtual Directory Creation Wizard. Complete the wizard to add a new virtual
directory.
Entering and exiting Live Data view
Dreamweaver provides three different methods for invoking Live Data view. Use the tech-
nique that best suits your work style:
✦ Choose View ➪ Live Data from the main menu.
✦ Use the keyboard shortcut Ctrl+Shift+R (Command+Shift+R).
✦ Click the Show Live Data View button on the toolbar.
In Live Data view, executing any of these three actions returns you to Standard mode, where
you see dynamic data placeholders.
If, for any reason, you need to interrupt the Live Data connection process, click the Stop but-
ton on the Live Data toolbar. The Stop button remains active only while Dreamweaver is
transitioning into Live Data view.
Tip
543504 ch21.qxd 12/10/03 10:37 PM Page 712
713
Chapter 21 ✦ Working with Live Data
Making changes in Live Data
If a feature in a software program can be said to have a raison d’etre, then modifying the lay-
out must surely be the raison d’etre of Live Data. When in Live Data view, new elements—
dynamic or static —may be added and existing ones adjusted or removed entirely. Anything,
including the dynamic data, may be formatted or styled using HTML or CSS.
Live Data view solves the thorny challenges of laying out a table without resorting to a time-
consuming trial-and-error approach. For example, varying lengths of data in the same column
often complicate designing table layout with dynamic data. If, for example, the sample data
includes a last name field that is 12 characters long and the real data contains a hyphenated
name that is 25 characters long, you have a problem. When working in Live Data view, you
can see the entire page as it would be generated on the server, including dynamic elements

and repeating table rows (see Figure 21-5).
Figure 21-5: Use Live Data view to make sure your table layout works well with the actual
data that appears on the page.
Stop
Refresh
Auto Refresh checkbox Live Data view
543504 ch21.qxd 12/10/03 10:37 PM Page 713
714
Part IV ✦ Incorporating Dynamic Data
The Live Data toolbar includes a Refresh button that, when clicked, resends your application
to the server for processing and then redisplays the page in the Document window. The
Refresh option is valuable in the following circumstances:
✦ Information from the data source is reassessed. This feature enables you to make
changes in the database and then see those changes incorporated into your page.
✦ Server formatting changes are applied to dynamic data. If you don’t refresh after alter-
ing the current format of the inserted data, the modified element reverts to being dis-
played as a dynamic data placeholder.
✦ HTML formatting applied to dynamic data is also applied to Live Data displayed
through a Repeat Region server behavior. Without refreshing, only the initial data is
shown correctly formatted.
Repeat Region server behaviors enable multiple records from the same recordset to be
incorporated into a page. For details on how to insert and manage a Repeat Region, see
Chapter 20.
The Live Data toolbar provides two refresh-oriented options: the Refresh Live Data button
and the Auto Refresh checkbox. When Auto Refresh is enabled, formatting changes are auto-
matically applied. However, to display HTML formatting on Repeat Region data or to see
changes made to a data source, you must select the Refresh Live Data button.
Live Data Settings
Although the capability to work with data from the current recordset is impressive, it’s really
only half the story of Live Data view. Many Web applications depend on variables used when

the page is processed by the testing server. Users may intentionally submit these variables
when they fill out a form or they may submit variables unintentionally when they navigate
from a particular page. Session or application variables, from authentication routines or sim-
ple counters, may also be integrated into a page. Dreamweaver permits developers to interac-
tively alter all such variables and preview the resulting Web page. This facility not only
enables the Dreamweaver designer to work with a wide range of real-life conditions, it also
facilitates testing of the application under a variety of circumstances. Dreamweaver offers
two avenues of approach to variable handling: through the query string field or through the
Settings dialog box.
Getting the query string
Remember the first time you noticed that the link you clicked was carrying quite a bit of addi-
tional baggage? Where you might have selected a link that took you to a specific product page
with a URL such as
the link in the
Location field of your browser looked more like the following:
/>widget&sessionID=2343215&login=no&visited=gadgets%20%r%20us
The text following the question mark is called a query string, or the URL parameters. Query
strings are a tool used by Web applications to pass information from one page to the next.
Frequently, you see a query string after submitting a form. Forms using the
Get method pass
Cross-
Reference
543504 ch21.qxd 12/10/03 10:37 PM Page 714
715
Chapter 21 ✦ Working with Live Data
their variables by appending a question mark and the form information to the URL of the
requested page. The form information is in a series of name/value pairs; and each name/
value pair is linked by an equals sign, as follows:
Firstname=Joseph
Query strings may include any number of name/value pairs, separated by an ampersand.

Thus, for a form that passes the data entered into a first name field and a last name field,
the query string may look like the following:
?firstname=Joseph&lastname=Lowery
Note that neither single nor double quotes are used because they are in HTML attributes.
Quotes and other characters —including spaces, apostrophes, and tildes —are represented
by hexadecimal values so that they are properly understood by servers. Such strings are said
to be URL encoded, and they are designated by an initial percent sign, followed by the ASCII
value of the character in hexadecimal. Some commonly used encoding values are as follows:
✦ Space: %20
✦ Apostrophe or single quote (
‘): %27
✦ Double quote (
“): %22
✦ Tilde (
~): %7E
✦ Less than (
<): %3C
✦ Greater than (
>): %3E
The query string field appears in the Live Data toolbar by default, prefaced by the URL path
used by Live Data plus a question mark. The URL path, question mark, and the text entered
into the field comprise the complete URL submitted to the testing server when you invoke or
refresh Live Data.
Depending on the length of the pathname, some elements, such as folders, may be repre-
sented by an ellipsis (three dots) so that Dreamweaver may display the filename and ques-
tion mark.
Consider an example that uses the query string. Suppose that you’ve developed a page for an
organization that displays employees and whether they’re under contract. The contract sta-
tus shown depends on the link selected by the user; the links are identical except for the query
string portion. For uncontracted employees, the link reads

employees.cfm?contract=no,
whereas for contracted employees, the link reads
employees.cfm?contract=yes. The
recordset on the
employees.cfm page uses a filter that sets the Contract field equal to the
URL parameter called
contract.
Although the query string field is present by default, you can disable it by switching the
Method option in the Live Data Settings dialog box from Get to Post. To re-enable the query
string field, choose View➪ Live Data Settings and select Get as the Method option.
After entering Live Data view by any of the methods described previously, you can switch
back and forth between the two sets of returned data by changing the value in the query
string
name=value pair. In this instance, the two accepted values— as defined in the data
source—are
no for employees not under contract and yes for employees under contract.
Note
Note
543504 ch21.qxd 12/10/03 10:37 PM Page 715
716
Part IV ✦ Incorporating Dynamic Data
After changing the value and pressing Enter (Return), the Live Data is refreshed, as shown in
Figure 21-6.
Figure 21-6: You may use the query string field of the Live Data toolbar to test different
scenarios for your Web application.
If you encounter a Live Data error indicating that the page cannot be displayed because the
current record could not be found, you’re probably including values in the query string that
do not match any records in a recordset on the page. You have a couple of options for pro-
ceeding. Press the Esc key to dismiss the error dialog box and enter a new value in the query
string field. (Don’t click the Close button on the dialog box, or you’ll close the Live Data view

and the Live Data toolbar.) Alternatively, you can enter a name value/pair through the Live
Data Settings dialog box as outlined in the following section.
Posting responses with Live Data settings
Although the query string is handy for changing one or two simple variables, the more com-
plex the variables, the less convenient it becomes. Dreamweaver offers another route to con-
trolling Live Data variables: Live Data settings. The Live Data Settings dialog box, shown in
Figure 21-7, offers several important advantages over the query string:
Caution
Query String field
543504 ch21.qxd 12/10/03 10:37 PM Page 716
717
Chapter 21 ✦ Working with Live Data
✦ The name/value pairs are easier to enter and maintain in a straightforward two-column
table.
✦ URL encoding is handled automatically by Dreamweaver; with query strings. You have
to enter any necessary URL encoding manually.
✦ Variables may be sent to the application by either the
Get or Post method. The query
string uses only the
Get method.
✦ Additional initializing code may be applied to the page. This feature enables you to
test different session or environmental variables in the page, as if the server had set
the values.
✦ Variable settings may be optionally stored. If you select this option, Dreamweaver uses
its Design Notes facility to maintain the variables.
Figure 21-7: You can use the Live Data Settings dialog box
to simulate forms using either the GET or POST method.
To establish variables using the Live Data Settings feature, follow these steps:
1. Choose View➪Live Data Settings or enter Live Data view and select Settings from the
Live Data toolbar. The Live Data Settings dialog box for the current page is displayed.

2. To create a new variable, choose the Add (+) button.
3. In the Name column, enter the name of the variable.
4. In the corresponding field under the Value column, enter a value for the variable.
5. Repeat Steps 2 through 4 to add additional variables.
6. To delete a name/value pair, select it and then choose the Remove button.
7. You can adjust the sequence in which the variables are presented to the page by using
the Up and Down buttons to move name/value pairs higher or lower in the list.
8. By default, Dreamweaver sends variables to a page using the
Get method, which
appends URL-encoded name/value pairs in a query string. To simulate a form passing
variables in an encapsulated, hidden manner, choose
Post from the Method list.
543504 ch21.qxd 12/10/03 10:37 PM Page 717
718
Part IV ✦ Incorporating Dynamic Data
If you choose the Get method, enter the variables and their values without encoding them
for the URL. Dreamweaver translates any necessary characters into their hexadecimal equiv-
alents when the Live Data page is processed.
9. To establish a particular server environment, enter any necessary code in the
Initialization Script text area. This code is specific to each server model and must
be completely self-contained within any required tags or delimiters.
10. To store your variable settings, select the Save Settings For This Document option.
Dreamweaver requires that Design Notes be enabled in order to save the Live Data
settings. If Design Notes is disabled when you select this option, you get an oppor-
tunity to enable it.
Previewing in the Browser
Live Data saves a tremendous amount of time in the early design phase. However, when it
comes time to test your application in various browsers—a necessary step for virtually all
Web developers —there is no substitute for previewing in the browser. Dreamweaver does
a decent job of approximating a browser-eye view of your page. However, with so many varia-

tions between the major browsers— not to mention the versions within each major browser—
you must test your page in as many browsers as possible. Dreamweaver’s Preview in Browser
feature enables you to specify up to 13 different browsers in Preferences. After this feature is
defined, you may test your page by choosing File ➪ Preview in Browser➪Browser Name at
any point. If the toolbar is available, you may also choose a browser under the Preview/
Debug in Browser option.
Previewing in the browser was a major Dreamweaver 4 enhancement that, in Dreamweaver
MX and now in MX 2004, carries one additional responsibility. In order to view Web applica-
tions properly, Dreamweaver must process the pages with a testing server. To use this facility,
you must satisfy two requirements:
✦ Specify the route to the testing server, either via a local (or networked) folder or
through FTP in the Testing Server category of the Site Definition dialog box.
✦ Transfer any dependent or related files to the testing server. Although you don’t have
to include dependent files such as graphics on the current page, you must transfer
server-side includes, such as the connection script. Related files are other pages refer-
enced in the Web application; Dreamweaver only uploads a copy of the current page
during the Preview in Browser operation.
When the testing server is properly set up (as described in Chapter 5), you can transfer any
necessary files quickly in the Site window. From the Site window toolbar, select the Testing
Server button. The files on the testing server are displayed in the Testing Server pane of the
Site window, as shown in Figure 21-8. Transfer files from the local site by dragging them from
the local pane to the Testing Server pane or by selecting the files and then choosing the Put
or Check In button.
Tip
543504 ch21.qxd 12/10/03 10:37 PM Page 718