Previous Section  < Day Day Up >  Next Section

24.2 Additional Data Sources

So far, you've been using Dreamweaver's dynamic page-building features to retrieve information from databases for building catalog pages, product detail pages, and other pages that require database-generated content. But at times, you'll want to collect data from other sources and add them to your page. For example, when someone logs into a site (see the Log In User server behavior in Section 24.1.3), her user name travels along with her from page to page in what's called a session variable. Using the Bindings panel, you can capture this session name and then use it on a Web page.

Similarly, you can create cookies to store small pieces of information on a person's computer梥uch as a counter tracking how many times he's been to your site梐nd use Dreamweaver's Bindings panel to add that information to a Web page.

The Bindings panel lets you access these sources of data as well as information submitted from form fields and embedded in URLs. Each server model understands different types of dynamic data, but most recognize the ones listed below.


ASP.NET note桪reamweaver doesn't let you add any of these additional data sources to the Bindings panel.

Regardless of the type of dynamic data you wish to add, the process is essentially the same. It differs only between server models.

24.2.1 For ASP

  1. Click the + button in the Bindings panel. Depending on the type of dynamic data you're interested in, select either Request Variable, Session Variable, or Application Variable.

    In ASP, the Request Variable covers a wide range of data sources, including form variables, URL variables, cookies, and server variables, so there's an extra step you must perform. After selecting Request Variable to open the Request Variable window (see Figure 24-6), choose a type of variable from the Type menu.

  2. Type the name of the variable into the Name field.

    Capitalization doesn't matter. To ASP, username, UserName, and USERNAME are all the same.

  3. Click OK.

    Dreamweaver adds the variable to the Bindings panel.


These steps don't actually create the variable; they only let you find out what's stored in a variable that's already been created. For example, adding a cookie variable in the Bindings panel doesn't actually create a cookie on a visitor's system. (For information on creating cookies, see Section 24.2.6.)

The Request Variable window (for the ASP server model only) lets you add a wide variety of variable types for use in an ASP page. Request. QueryString is ASP's way of referring to a URL variable.

24.2.2 For PHP and ColdFusion:

  1. Click the + button in the Bindings panel and select the proper variable type: URL, Form, Cookie, or whatever.

    A window appears for the particular type of data source.

  2. Type the name of the variable in the Name field.

    This time, capitalization matters; username, UserName, and USERNAME are all different variables. Find a system you're comfortable with (all lowercase, all uppercase, or mixed case) and stick with it.

  3. Click OK.

    Dreamweaver adds the URL variable to the Bindings panel.

24.2.3 For JSP:

For JSP pages, Dreamweaver supplies tools for adding only form, URL, and session variables.

  1. Click the + button in the Bindings panel and select either Request Variable or Session variable.

    Depending on the choice, either the Request Variable or Session Variable dialog box appears.

  2. Type the name of the variable into the Name field.

    Here again, capitalization matters, so username, UserName, and USERNAME are all different variables.

  3. Click OK.

    Dreamweaver adds the URL variable to the Bindings panel.

After you add the variable to the Bindings panel, you can drag it to your Web page; any of the techniques for adding recordset data to a page also work (see Section 22.1.2). Unfortunately, unlike recordsets, you can't copy and paste these variables from page to page.

You can drag data sources listed in the Bindings panel into Code view, as well. Once you've got your programming chops sharpened, this trick is helpful for quickly adding data to your own server-side programs.

24.2.4 URL Variables

Some URLs include information tagged onto the end of the name of a Web page like this: . The information following the ? is known as a query string, and it provides additional information to a dynamic page.

In most cases, this information comes in the form of one or more name/value pairs, which Dreamweaver refers to as URL variables. In this example, the name of the URL variable is prodID, and its value is 4. URL variables are often used to transfer specific information for use in a recordset. You saw an example of this in the tutorial in Chapter 22: The number of a particular product was passed in a URL to the product details page, which used this number to retrieve details on a particular item.

You can also add a URL variable to the Bindings panel, and then include it in a Web page or use it anywhere you'd use a dynamic data source. For example, you can use it as a parameter added onto the end of a link in order to hand off the information along to another page.

Keep in mind that a page that links to the page with the URL variable must include the proper query string in the link. For example, say you add a URL variable named "username" to the page crop_circles.html; the page uses the query string to personalize the page: "Welcome, [username]". For this to work, you then need to link to the crop_circles.html page with the query string attached to the URL like this: crop_circles. html?username=bob.

You can add a URL variable to the Bindings panel using the methods described in Section


Don't use this method for accessing private or sensitive data. For example, suppose you used a URL variable as a method for accessing personal data of one of your customers, like this: customer_data. asp?customerID=78. A nefarious visitor could just change the number in the URL梩o, say, 79梩o view all of the personal data for customer number 79.

24.2.5 Form Variables

You can also add information from forms to the Bindings panel and use them on your page. If you add a form on one page, you can collect that information on the page the form submits to (the same page specified in the form's Action property, as described in Section 11.2). In other words, the page receiving the form data can display that information on the page or use it in some other fashion梥uch as inserting the information into the database, or creating a cookie or session variable.

If you're mainly using forms in conjunction with Dreamweaver MX 2004's Insert Record and Update Record server behaviors, you won't generally take advantage of form variables. Those two behaviors work by collecting data from a form, adding or updating a database record, and then redirecting the Web browser to another page. The page the visitor finally sees never has access to the form information, so you can't add any form variables to that page.

However, adding a form variable to the Bindings panel can come in handy when you create a search page. For example, suppose you've created a page for searching a database. The search form lets the visitor type in a name梠f an author or musician, for instance. You could then create a search results page that looks in the database for any records that match the search term. On that page, along with the database results, you could add text like "Search Results for: [search_term]," where search_term would be the word the visitor typed into the form. Just add the form variable to the Bindings panel and then drag it to the spot in the search page where you wish it to appear.


If you use the GET method for submitting a form, the names and values of each form field are included in the URL. In this case, they're considered URL variables, so if you wish to add any of these fields to the Bindings panel, use the URL variable method instead. (For the difference between GET and POST, see Section 11.2.)

24.2.6 Cookies

One problem with Web servers is that they have no memory.

Suppose, for example, that a site has a particularly long and annoying Flash movie that welcomes visitors with an ear-pounding, seizure-inducing multimedia display. Even if the designer was kind enough to include a "Skip this nauseating display" button, the Web server won't remember that you clicked it the last time you were there.

To overcome this limitation, most Web browsers store cookies梥mall text files containing specific information梩hat Web servers can create and read. In the example above, the Web server could drop a cookie onto your computer when you click the "Skip intro" button. The next time you visit the site, the Web server reads the cookie and kindly ushers you past the Flash movie and directly to the home page.

You can use cookies to store information on visitors' computers, too. They're a great way to store customer ID numbers, the number of visits to a particular page, and other bits of identifying information.

Cookies play by a few rules:

  • A single cookie is stored on just one browser and one computer at a time. If you log onto a site that adds a cookie to your computer, and then log on again later from the public library, that computer won't have access to the cookie. In fact, if you use a different Web browser on the same computer, the Web server won't be able to read the original cookie from the other browser. (A variation: In some corporations, a Web browser stores cookies on a network server. This kind of cookie can be accessed by a particular browser桰nternet Explorer, for example梠n different computers on the network.)

  • Only the domain that created the cookie can read it. You can't create dynamic pages that read a cookie set by, for example. Fortunately, that means other Web sites can't read the cookies you set on your visitors' computers, either.

  • Web browsers can only store 300 cookies total, and each cookie can be no larger than 4 K in size, so that hard drives won't crumble under their weight.

Adding and Deleting Cookies Using ASP Pages

While Dreamweaver doesn't provide a tool for adding the scripts necessary to create and delete cookies with ASP pages, it isn't difficult to add the code yourself. (Dreamweaver can easily retrieve cookie information, as described in Section 24.2.)

First, decide which page should add the cookie. The script will run when a visitor's browser requests the page, sending the cookie to the browser before the page content. Thus, you could add a script like this at the beginning of a form processing page. For example, if someone registers at your site, your script can store the name he enters in the registration form as a cookie on his computer. When he returns to the site, the home page can then read the cookie and display "Welcome back, Bob"梐ssuming, of course, that his name is Bob.

To add a cookie, use this code:



= "value_of_cookie"


Expires = Date + 30


Remember to include the opening <% and closing %>, which tell the application server that everything in between is programming code and not HTML. Replace name_of_cookie with whatever name you wish to give the cookie: username, for example. Also replace value_of_cookie with whatever you want to store in the cookie. In many cases, this will be a dynamic value梚nformation from a recordset, a URL variable, or a form variable, for example. Using the steps described in Section 24.2, add the appropriate dynamic data to the Bindings panel, then drag it into the code directly after the = sign (omit the quote marks [""]).

The next line of code sets an expiration date. In this case, Date + 30 means 30 days from today. You must set an expiration date; if you don't, the cookie will last only as long as the visitor's browser remains open.

One thing to keep in mind: where you place the code will effect when the cookie is set. For example, if you put the cookie-setting code below the first line of code in Code View, then server will deliver the cookie before doing anything else. However, if you want to set the value of a cookie using information retrieved from a recordset, then you need to place the cookie code after the recordset code.

You may also want to delete a cookie at some point. For example, on an ecommerce site, you could use a cookie to store items a visitor adds to her shopping cart. When she wanted to empty her cart梐fter she purchases everything in it, for example梱ou could simply delete the cookie. Just assign no value to the cookie you wish to delete, like this:



= ""


If you find yourself typing this code a lot, you can save yourself some time by turning the programming code into Snippets (Section 17.1).

You can add a cookie to the Bindings panel using the method described in Section 24.2. Unfortunately, Dreamweaver MX 2004 doesn't provide any tools for creating cookies (send your feature requests for the next version of Dreamweaver to: wishdreamweaver@ ). Several third-party developers have risen to the occasion, however:

  • PHP developers. Dreamweaver Extension developer Felice Di Stefano has developed a free cookie extension for the PHP server model. It includes server behaviors for adding and deleting cookies from a PHP page. In addition, it can set a cookie to the value of a form field, or redirect a visitor to another page if a specific cookie doesn't exist, or if it matches a particular value. You can find it at the Macromedia Exchange or at .

  • ColdFusion developers. Basic UltraDev distributes a free extension called CF_ Cookie. You'll find it in the extensions section of their site: www.basic-ultradev. com/extensions/index.asp .

  • JavaScript cookies. You can also use JavaScript to set cookies. This technique works with any type of page梕ven nondynamic pages. The only catch is that the visitor's browser must both understand JavaScript and have JavaScript enabled (most do).

    XM Extensions ( ) offers both free (basic) and commercial (full-featured) cookie extensions. But for the king of cookie creators, check out WebAssist's Cookies extension at asp?PID=6 .


ASP note桽ee the box in Section 24.2.6 for information on how to add cookies yourself.

24.2.7 Session Variables

Web servers don't know or care whether the person requesting your company's home page just placed a $10 million order, or is a first-time visitor. Of course, you probably care, and so do most Web applications, which need to follow visitors as they travel a site. For example, in a typical ecommerce site, people use a "shopping cart" to store items they're interested in purchasing. For this to work, however, you need to track each shopper's movement from page to page.

To make this possible, most Web servers recognize what are called session variables. A session variable is created by the Web developer (or more accurately, by a dynamic Web page that creates the variable) and follows the visitor from page to page. This type of variable lasts, logically enough, for a single session: If the visitor closes the browser, the session ends and the variable disappears. Most Web servers also add a limited time that the variable sticks around梪sually 20 minutes. In other words, if the visitor doesn't hit any page in the site for 20 minutes, the Web server assumes that she's no longer around and destroys the session variable.


Session variables take up resources from the Web server. That's why a Web server gets rid of them as soon as it can. Creating lots of server variables for a busy Web site can slow down the server.

When it creates a session variable, the Web server sends a cookie to the visitor's machine. The cookie contains a unique number (not the actual data contained in the variable), which the server uses to keep track of each visitor. When that person requests a page, the Web server reads the cookie with the unique ID. It can then retrieve session variables for that individual. For this reason, session variables won't work if the visitor's Web browser doesn't accept cookies.


Dreamweaver itself creates session variables when you use the User Authentication server behaviors. See Section 24.1.4 for a discussion of these session variables and how you can use them.

You may be wondering how cookies and server variables differ and when you'd want to use one over the other. The difference is that cookies can last between visits. If you want access to a piece of information when a visitor comes back tomorrow, or next week, or next month, use a cookie. For example, you'd use a cookie to remember a selection someone made from a previous visit, such as "Skip this crazy Flash Intro."

Adding and Deleting Session Variables Using ASP Pages

While Dreamweaver doesn't provide a simple wizard for adding the code necessary to create and delete session variables with ASP pages, it isn't difficult to add it yourself. (Dreamweaver does, however, make quick work of retrieving session variables; see Section 24.2).

The procedure is much like the one for adding cookies (see the box in Section 24.2.6)梖or example, here again, the script will run when a visitor requests the page. When people register at your site, therefore, the email address they enter in the registration form could be stored as a session variable.

To add a session variable, use this code:


Session("name_of_variable") =



Replace name_of_variable with whatever name you wish to give the server variable: email, for example. Also replace value_of_variable with whatever you want to store in the session variable. In many cases, this will be a dynamic value like information from a recordset, a URL variable, or a form variable. Using the steps described in Section 24.2, add the appropriate dynamic data to the Bindings panel, and then drag it into the spot in the above code just after the = sign (in this case, omit the set of double quote marks: ""). As with cookies, where you place the session-creating code determines when it kicks in. So if you want to set a session with a value from a recordset, place the session code after the code that creates the recordset.

You may also want to delete a session variable to conserve server resources. (Dreamweaver's Log Out User server behavior uses this method to log a visitor out of a site.) To delete a server variable, add this code to the beginning of a page:





To delete all session variables for a particular individual in one fell swoop, use this code:




Session variables, on the other hand, provide better security. The actual information stored in the session variable stays on the Web server, while cookies exist as text files on a computer and can be opened and read by anyone with access to the computer. Accordingly, if you need to keep track of a confidential piece of information (someone's bank-account password, for example), you'd use a session variable.

You can add a session variable to the Bindings panel using the method described in Section 24.2.

Unfortunately, as with cookies, Dreamweaver MX 2004 doesn't provide any tools for creating or destroying session variables. To find third-party extensions that work with session variables, try the Macromedia Exchange ( ). Click the Dreamweaver link, and search using the term session.


PHP note桭elice Di Stefano has developed a free session extension for the PHP server model. It includes server behaviors for adding and deleting session variables from a PHP page. You can find it at the Macromedia Exchange or .

24.2.8 Server Variables

Web servers collect and produce lots of information, much of which is hidden from the everyday Web surfer (and even the everyday Webmaster). Some of that information is obscure, but some can come in handy. For example, you can find out which Web browser the visitor is using, or which language the browser uses. While the exact list of server variables differs by Web server, here are some useful variables that work on many Web servers:

  • HTTP_USER_AGENT. Information about the browser visiting the page. Unfortunately, you don't get a neat little summary like Microsoft Internet Explorer 6 for Windows. Instead, browser information is usually rather long-winded: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET CLR 1.0.3705).

  • REMOTE_ADDR. The IP address of the computer requesting the Web page. It'll look something like Depending on the visitor's setup, this could be the exact address of the computer. (Big Brother, where art thou?)

    Knowing this address has its uses. If someone frequently causes problems on your site梡osts phony information to registration forms, say, or submits offensive messages to a message board梠ne potential solution is to prevent submissions to your database from that particular IP address. (However, since dial-up users usually receive a different IP address each time they dial in, this isn't a foolproof solution.)

  • HTTP_REFERER. This is the URL of the page that leads to the current page. For example, say you click a link on page A to get to page B. Page B's HTTP_REFERER server variable would be A.

    You could use this knowledge to create the ultimate Back button. Simply add the HTTP_REFERER server variable to the Bindings panel. Then add a link to whatever you wish to be the Back button梘raphic or text梐nd use the server variable as the link. When visitors click this link, it will take them back to whichever page brought them there in the first place.

For a list of server variables supported by Microsoft's IIS Web server, visit msdn. . For a list of server variables for use with the Apache Web server, visit html .

    Previous Section  < Day Day Up >  Next Section