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—such as a counter tracking how many times he's been to your site—and 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.

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

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:

24.2.3 For JSP:

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

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: www.nationalexasperater.com/catalog.asp?prodID=4 . 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 22.1.5.2.

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—such 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—of 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.

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—small text files containing specific information—that 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—Internet Explorer, for example—on 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 Amazon.com, 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.

POWER USERS' CLINIC 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"—assuming, of course, that his name is Bob. To add a cookie, use this code: <% Response.Cookies("name_of_cookie") = "value_of_cookie" Response.Cookies("name_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—information 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—after she purchases everything in it, for example—you could simply delete the cookie. Just assign no value to the cookie you wish to delete, like this: <% Response.Cookies("name_of_cookie") = "" %> 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@ macromedia.com ). 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 www.felixone.it .

• 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—even nondynamic pages. The only catch is that the visitor's browser must both understand JavaScript and have JavaScript enabled (most do).

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

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—usually 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.

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.

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."

POWER USERS' CLINIC 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)—for 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") = "value_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: <% Session.Contents.Remove("name_of_ variable") %> To delete all session variables for a particular individual in one fell swoop, use this code: <% Session.Abandon %>

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 ( www.macromedia.com/exchange/ ). Click the Dreamweaver link, and search using the term session.

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 65.57.83.12. 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—posts phony information to registration forms, say, or submits offensive messages to a message board—one 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—graphic or text—and 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. microsoft.com/library/en-us/iisref/htm/readme_dumpvars.asp . For a list of server variables for use with the Apache Web server, visit hoohoo.ncsa.uiuc.edu/cgi/env. html .