Dreamweaver.MX.1002004.The.Missing.Manual [Electronic resources] نسخه متنی

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
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 noteDreamweaver 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

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.

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

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.

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

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.

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 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:
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_circlesl; the page uses the query string to personalize
the page: "Welcome, [username]". For this to work, you then need to link to the
crop_circlesl 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.

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 personal data of one of your customers, like this: customer_data.
asp?customerID=78. A nefarious visitor could just change the number in the URLto, say, 79to 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 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 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 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 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 cookiessmall 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 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 valueinformation 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 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 (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:
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).

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
.

NOTE

ASP noteSee 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 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
she'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 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.

NOTE

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

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.

NOTE

PHP noteFelice 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
.

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

Dreamweaver.MX.1002004.The.Missing.Manual [Electronic resources] نسخه متنی

فارسی

کردی

العربیه

اردو

Türkçe

Русский

English

Français

کانال فیلم من

تبیان من

فایلهای من

کتابخانه من

پنل پیامکی

وبلاگ من

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی