Your Application. cfm template is where you define the settings for your application.
The following list demonstrates various types of functionality you can code into your Application. cfm template; you can:
• Enable session, client, and application management, which allows you to use session, client, and application variables
• Set timeouts for the application and any sessions tied to it
• Define the location where you want to store client variables
• Define global settings such as data sources, fonts, colors, etc.
• Authorize access to the application templates by verifying user permissions
• Account for application errors and create customized error pages
To enable session, client, and application management in an Appl icat; on. cfm ternplate, you should use the CFAPPLICATIONtag. The following code displays the syntax for the CFAPPLICATIONtag and the attributes of this tag.
A basic Applcation. cfm template might look like that in the following code. This code shows how to turn on session management, set tirneouts for both the application and a user session, turn on client management, set application and server constants such as standard background color and font face, and test whether a user has logged in. You are not expected to understand the code at this point; later in this chapter you will learn in more detail about the interactions coded in this template.
Working with Application Scope
Now that you know how to create the Application. cfm template, you need to learn how to use the variables associated with the ColdFusiori Application Framework. These variables are listed in Table 17.1. Each of these variable types has a particular scope within the framework of the application. The scope refers to the time and location that a particular variable is available for use. It is important to understand the different scopes of each application variable type in order to know when a variable should be used. If you use the wrong type of variable at the wrong time, you could risk making your application insecure, loading too much data into the server’s memory, or losing information that you wanted to store indefinitely. Table 17.1 briefly details the scope of each type of variable. A more in-depth discussion of each variable scope is included in other sections of this chapter.
Using Client Management
Client variables are associated with a singleclient (or browser) and can persist over multiple sessions. This means that if you set a client variable for a user who has visited your site, that variable will be stored and can be retrieved during the user’s next visit (provided they connect using the same client). If Person A and Person B visit your site, each will have access only to the client variables set for their client. Person A would not be able to see Person B’s client variables. This restriction is useful because it enables you to track user information over a period of visits.
ColdFusion defines a client through the application name specified in the (FAPPLICATION tag and by setting two cookies: (FID and (FTOKEN)
CFID An incremented ID for each client that connects to the server
CFTOKEN A random number used in conjunction with (nD to uniquely identify a particular client
Cold Fusion sets these cookies only once (in previous versions they were set at every page request). ColdFusion, by default, also stores these two variables in the registry with any other client variables that have been set. The registry is the default storage mechanism, but cookies or a data source can also be used.
When a user connects to an application with (1; entManagement enabled, ColdFusion determines whether the (FID and (FTOKEN cookies exist. If they do, then the associated client variables are stored in the specified storage mechanism (the registry is the default) and are available for use to that client. If not, then ColdFusion sets a (FTOKEN for that client in the storage mechanism and with-the client (using cookies).
Another client variable. called URLTOKEN, is added to the storage device. This is a combination of the C::FID and CFTOKEN variables. URLTOKEN can be used to pass the CFID and CFTOKEN values through URL or form parameters in case cookies have been disabled on the client side.
Examples of using client variables include storing the following:
• User display preferences such as background colors, page layouts, font faces
• User content preferences such as feature stories, stock preferences, favorite links
• Counts of how many times a user has visited and when they visited last
• Items in a shopping cart and past purchases
• Scores for quizzes or games
Because the default storage space for client variables is the registry, it is wise not to store too much information in client variables.
Enabling Client State Management
Client variables are enabled using the CFAPPLICA TION tag in the App 1; cat; on. cfm template, Because client variables are tied to a particular application, a name must be specified in the CFAPPLICATION tag by using the NAMEattribute. The CLIENTMANAGEMENT attribute must also be set to YES. The location to store all client variables can be specified using the CLIENTSTORAGE attribute. The default storage space is the registry. The optional storage spaces include:
Registry Variables are stored by default for 90 days.
Cookie All built-in client variables and any client variables set within an application are stored in the CFGlOBALS cookie on the client side. There are limitations to using cook; e for storing your client variables. These limitatims are discussed in more detail later in this section, The default storage time for cookies is approximately 38 years.
External data source An OOBC or native data source can be used to store client variables for a default of 10 days. This data source needs to be set up in the ColdFusion Administrator as described later in this section.