Section 23.2. Additional Data Sources

23.2. Additional Data Sources

So far, you've been using Dreamweaver's dynamic page-building features to retrieve information from databases to build 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 on Section 23.4.1), 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 computersuch as a counter tracking how many times he's been to your siteand 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.

Note: ASP.NET note : Dreamweaver 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 of accessing these data sources is essentially the same. It differs only among server models.

23.2.1. For ASP

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, 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 23-6), choose a type of variable from the Type menu.

Figure 23-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.
Type the name of the variable into the Name field .

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

Dreamweaver adds the variable to the Bindings panel.

Note: 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, and then use it on a Web page. 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 23.2.6.)

23.2.2. For PHP and ColdFusion

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

A window appears for the particular type of data source.
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.
Click OK .

Dreamweaver adds the variable to the Bindings panel.

23.2.3. For JSP

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

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

Depending on the choice, either the Request Variable or Session Variable dialog box appears.
Type the name of the variable into the Name field .

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

Dreamweaver adds the 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 21.1.2), and you can use them whenever the Dynamic Data window appears (see Figure 22-7), for example, as the content of a form field.

Tip: 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.

23.2.4. URL Variables

Some URLs include information tagged onto the end of the name of a Web page, like this: www.nationalExasperator.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 21: 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 to hand off the information to another page.

Keep in mind that a page that links to the page using 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 a link using the methods described on Section 21.1.5.3.

Note: Don't use this method for accessing private or sensitive data. For example, suppose you used a URL variable as a method for accessing the 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 to, say, 79 to view all of the personal data for customer number 79.

23.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 then collect that information on the page the form submits to (the same page specified in the form's Action property, as described on Section 10.2). In other words, the page receiving the form data can display that information on the page or use it in some other fashionsuch as inserting the information into the database, or creating a cookie or session variable.

If you're mainly using forms in conjunction with Dreamweaver'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 nameof 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.

Note: 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 10.2.)

23.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 informationthat 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 browserInternet Explorer, for exampleon 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 KB 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 on Section 23.2.1.)

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 valueinformation from a recordset, a URL variable, or a form variable, for example. Using the steps described on Section 23.2.1, add the appropriate dynamic data to the Bindings panel, and 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 the 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 e-commerce site, you could use a cookie to store items a visitor adds to her shopping cart. When she wants to empty her cartafter she purchases everything in it, for exampleyou 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 (see Section 16.1).

You can add a cookie to the Bindings panel using the method described on Section 23.2.1. Unfortunately, Dreamweaver doesn't provide any tools for creating cookies (send your feature requests for the next version of Dreamweaver to: wish-dreamweaver@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 pageeven nondynamic pages. The only catch is that the visitor's browser must both understand JavaScript and have JavaScript enabled (most do). Dreamweaver comes with two Snippets for setting and reading cookies using JavaScript. They're in the cookies folder of the JavaScript folder in the Snippets panel. See Chapter 16 to learn about Snippets. For the king of JavaScript cookie creators , check out WebAssist's Cookies extension at www.webassist.com/Products/ProductDetails.asp?PID=6.

Note: ASP note : See the box on Section 23.2.6 for information on how to add cookies yourself.

23.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 through a site. For example, in a typical e-commerce 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 aroundusually 20 minutes. In other words, if the visitor doesn't hit any page in the site for 20 minutes, the Web server assumes that he's no longer around and destroys the session variable.

Note: 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 session 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. (PHP, however, has a built-in method for maintaining session information even when cookies aren't turned on.)

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

You may be wondering how cookies and session 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 23.2.1.)

The procedure is much like the one for adding cookies (see the box on Section 23.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 session 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 on Section 23.2.1, add the appropriate dynamic data to the Bindings panel, and then drag it into the spot in the code in the previous column 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 on Section 23.2.1.

Unfortunately, as with cookies, Dreamweaver 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 .

Note: PHP note : Felice 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 www.felixone.it.

23.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 info is usually rather long-winded, like: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET CLR 1.0.3705) . For a discussion on how to decipher this confusing jumble of information, visit http://perl.about.com/od/cgiprogramminginperl/a/020905.htm.
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 siteposts phony information to registration forms, say, or submits offensive messages to a message boardone potential solution is to prevent submissions to your database from that particular IP address. (However, since many users' IP addresses frequently change, 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 buttongraphic or textand 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 the Microsoft Developer's Network site at http://msdn.microsoft.com/library/ and search for IIS Server Variables . For a list of server variables for use with the Apache Web server, visit http://hoohoo.ncsa.uiuc.edu/cgi/env.html.