The user interface has been simplified in Dreamweaver
CC and later. As a result, you may not find some of the options
described in this article in Dreamweaver CC and later. For more
information, see this article.

About dynamic content sources

A dynamic content source is
a store of information from which you can retrieve and display dynamic
content for use in a web page. Sources of dynamic content include
not only information stored in a database, but values submitted
by HTML forms, values contained in server objects, and other content
sources.

Dreamweaver lets you easily connect to
a database and create a recordset from which to extract dynamic
content. A recordset is the result of a database query.
It extracts the specific information you request and allows you
to display that information within a specified page. You define
the recordset based on the information contained in the database
and the content you want to display.

Different technology vendors may use different
terminology for a recordset. In ASP and ColdFusion, a recordset
is defined as a query. If you are using other sources
of data, such as user input or server variables, the name of the
data source that is defined in Dreamweaver is
the same as the data source name itself.

Dynamic websites require a data source from which to retrieve
and display dynamic content. Dreamweaver lets
you use databases, request variables, URL variables, server variables,
form variables, stored procedures, and other sources of dynamic
content. Depending on the data source, you can either retrieve new
content to satisfy a request, or modify the page to meet the needs of
users.

Any content source that you define in Dreamweaver is
added to the list of content sources in the Bindings panel. Then
you can insert the content source into the currently selected page.

About recordsets

Web pages can’t directly
access the data stored in a database. Instead, they interact with
a recordset. A recordset is a subset of the information
(records), extracted from the database using a database query.
A query is a search statement designed to find and extract specific
information from a database.

When using a database as a content source for a dynamic web page,
you must first create a recordset in which to store the retrieved
data. Recordsets serve as an intermediary between the database storing
the content and the application server generating the page. Recordsets
are temporarily stored in the application server’s memory for faster
data retrieval. The server discards the recordset when it is no
longer needed.

A query can produce a recordset that includes only certain columns,
only certain records, or a combination of both. A recordset can
also include all the records and columns of a database table. However,
because applications rarely need to use every piece of data in a
database, you should strive to make your recordsets as small as
possible. Because the web server temporarily holds the recordset
in memory, using a smaller recordset uses less memory, and can potentially improve
server performance.

Database queries are written in Structured Query Language (SQL,
pronounced “sequel”), a simple language that allows you to retrieve,
add, and delete data to and from a database. The SQL builder included
with Dreamweaver lets you create simple queries
without having to understand SQL. However, if you want to create
complex SQL queries, a basic knowledge of this language lets you
create more advanced queries, and provides you with greater flexibility
in designing dynamic pages.

Before you define a recordset for use with Dreamweaver, you must create a connection
to a database and—if no data exists yet—enter data into the database.
If you have not yet defined a database connection for your site,
refer to the database connection chapter for the server technology
you are developing for, and follow the instructions on creating
a database connection.

About URL and form parameters

URL parameters store retrieved information input by
users. To define a URL parameter you create a form or hypertext
link that uses the GET method to submit data. The
information is appended to the URL of the requested page and communicated
to the server. When using URL variables, the query string contains one
or more name-value pairs that are associated with the form fields.
These name-value pairs are appended to the URL.

Form parameters store retrieved information that is included
in the HTTP request for a web page. If you create a form that uses
the POST method, the data submitted by the form
is passed to the server. Before you begin, make sure you pass a
form parameter to the server.

About session variables

Session variables let you store and display information
maintained for the duration of a user’s visit (or session). The
server creates a different session object for each user and maintains
it for a set period of time or until the object is explicitly terminated.

Because session variables last throughout the user’s session
and persist when the user moves from page to page within the website,
they’re ideal for storing user preferences. Session variables can
also be used for inserting a value in the page’s HTML code, assigning
a value to a local variable, or providing a value to evaluate a
conditional expression.

Before defining session variables for a page, you must create
them in the source code. After you create a session variable in
the web application’s source code, you can use Dreamweaver to retrieve its value and use
it in a web page.

How session variables work

Session variables store
information (usually form or URL parameters submitted by users)
and make it available to all of a web application’s pages for the
duration of the user’s visit. For example, when users log on to
a web portal that provides access to e‑mail, stock quotes, weather
reports, and daily news, the web application stores the login information
in a session variable that identifies the user throughout the site’s
pages. This allows the user to see only the types of content they
have selected as they navigate through the site. Session variables
can also provide a safety mechanism by terminating the user’s session
if the account remains inactive for a certain period of time. This
also frees server memory and processing resources if the user forgets
to log off a website.

Session variables store information for the life of the use session.
The session begins when the user opens a page within the application
and ends when the user does not open another page in the application
for a certain period of time, or when the user explicitly terminates
the session (typically by clicking a “log-off” link). While it exists,
the session is specific to an individual user, and every user has a
separate session.

Use session variables to store information that every page in
a web application can access. The information can be as diverse
as the user’s name, preferred font size, or a flag indicating whether
the user has successfully logged in. Another common use of session
variables is to keep a running tally, such as the number of questions
answered correctly so far in an online quiz, or the products the
user selected so far from an online catalog.

Session variables can only function if the user’s browser is
configured to accept cookies. The server creates a session ID number
that uniquely identifies the user when the session is first initiated,
then sends a cookie containing the ID number to the user’s browser.
When the user requests another page on the server, the server reads
the cookie in the browser to identify the user and to retrieve the user’s
session variables stored in the server’s memory.

Collecting, storing, and retrieving
information in session variables

Before creating a session variable, you must first obtain
the information you want to store, and then send it to the server
for storage. You can gather and send information to the server using
HTML forms or hypertext links containing URL parameters. You can
also obtain information from cookies stored on the user’s computer,
from the HTTP headers sent by the user’s browser with a page request, or
from a database.

A typical example of storing URL parameters in session variables
is a product catalog that uses hard-coded URL parameters created
using a link to send product information back to the server to be
stored in a session variable. When a user clicks the “Add to shopping
cart” link, the product ID is stored in a session variable while
the user continues to shop. When the user proceeds to the check-out
page, the product ID stored in the session variable is retrieved.

A
form-based survey is a typical example of a page that stores form
parameters in session variables. The form sends the selected information
back to the server, where an application page scores the survey
and stores the responses in a session variable to be passed to an
application that might tally up the responses gathered from the
survey population. Or the information might be stored in a database
for later use.

After
information is sent to the server, you store the information in
session variables by adding the appropriate code for your server
model to the page specified by the URL or form parameter. Referred
to as the destination page, this page is specified
in either the action attribute of the HTML form
or the href attribute of the hypertext link on
the starting page.

After
you store a value in a session variable, you can use Dreamweaver to retrieve the value from session
variables and use it in a web application. After you define the
session variable in Dreamweaver, you can
insert its value in a page.

Both the server technology used and the method you use to obtain
the information determines the code used to store the information
in a session variable. The basic syntax for each server technology
is as follows:

ColdFusion

<CFSET session.variable_name = value>

ASP

<% Session("variable_name") = value %>

The value expression
is usually a server expression such as Request.Form(“lastname”).
For example, if you use a URL parameter called product (or
an HTML form with the GET method and a text field
called product) to gather information, the following
statements store the information in a session variable called prodID:

ColdFusion

<CFSET session.prodID = url.product>

ASP

<% Session("prodID") = Request.QueryString("product") %>

If
you use an HTML form with the post method and a
text field called txtProduct to gather the information,
then the following statements store the information in the session
variable:

ColdFusion

<CFSET session.prodID = form.txtProduct>

ASP

<% Session("prodID") = Request.Form("txtProduct") %>

Example of information stored in
session variables

You’re working on a site with a large audience of senior
citizens. In Dreamweaver, add two links to
the Welcome screen that let users customize the size of the site’s
text. For larger, easy-to-read text, the user clicks one link, and for
regular-size text, the user clicks another link.

Information stored in session variables

Each link has a URL parameter called fontsize that
submits the user’s text preference to the server, as the following
Adobe ColdFusion® example shows:

Store the user’s text preference in a session variable and use
it to set the font size on each page the user requests.

Near the top of the destination page, enter the following code
to create a session called font_pref that stores
the user’s font size preference.

ColdFusion

<CFSET session.font_pref = url.fontsize>

ASP

<% Session("font_pref") = Request.QueryString("fontsize") %>

When
the user clicks the hypertext link, the page sends the user’s text
preference in a URL parameter to the destination page. The code
on the destination page stores the URL parameter in the font_pref session
variable. For the duration of the user’s session, all the pages
of the application retrieve this value and display the selected
font size.

ASP and ColdFusion application
variables

In ASP and ColdFusion, you can use application variables
to store and display information that is maintained for the lifetime
of the application and persists from user to user. The application’s
lifetime lasts from the time the first user requests a page in the
application to the time the web server is stopped. (An application
is defined as all the files in a virtual directory and its subdirectories.)

Because application variables last for
the lifetime of the application, and persist from user to user,
they’re ideal for storing information that must exist for all users, such
as the current time and date. The value of the application variable
is defined in the application’s code.

ASP server variables

You can define the following ASP server variables as
sources of dynamic content: Request.Cookie, Request.QueryString, Request.Form, Request.ServerVariables,
and Request.ClientCertificates.

ColdFusion server variables

You can define the following ColdFusion server variables:

Client variables

Associate data with a specific client. Client variables maintain the
application’s state as the user moves from page to page in the application,
as well as from session to session. “Maintaining state” means to
preserve information from one page (or session) to the next so that
the application remembers the user, and the user’s previous choices
and preferences.

Cookie variables

Access cookies passed to the server by the browser.

CGI variables

Provide information about the server running ColdFusion,
the browser requesting a page, and other information about the processing environment.

Server variables

Can be accessed by all clients and applications on the server. They
persist until the server is stopped.