Dynamic content sources overview

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.

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.

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.

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.

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.

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.

The HTML syntax for each appears as follows:

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

ASP

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

ASP

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

ASP

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.

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

ASP

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.

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.

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

You can define the following ColdFusion server variables: