Read an Excerpt
Chapter I: Universal Considerations for Planning Your Application
The Application Scope
The first few lines of the sample Application.cfm file are, as always, our documentation header. A CFAPPLICATION tag comes next. This tag is used to define the scope of our application. An application scope defines how the application will deal with application, client, and session variables.First, we declare the name of the application. I gave this application the name "ChapterOne" because we are in Chapter 1 of the book. We won't actually get into a functional application until the second chapter. If you are going to use only client variables, you do not need to give your application a name, but I recommend that you always name your application. When working with other developers, or when using multiple applications in a single web site, it'll help if you have names to refer to the different sites.
The next portion of our CFAPPLICATION tag is the setclientcookies attribute. ColdFusion uses two values to keep track of individual users on the site: CFID and CFTOKEN. ColdFusion is specifically designed to work in cookies in this manner to keep track of a user's identity. The setclientcookies attribute tells ColdFusion to set a cookie on the user's machine with these two values if you choose Yes. If you choose No, you must manually pass CFID and CFTOKEN through each URL in the site, which can become a tedious development task. Because ColdFusion works this way, it is not uncommon for developers to disallow the use of their application by users who do not allow for the use of cookies with their browsers. Typically, this is done with some form of JavaScript in the Application.cfm file that will automatically redirect the user to a page explaining how the site uses cookies and why the current user cannot be allowed into the site until he or she resets the browser to allow for cookie usage.
Following setclientcookies is the setdomaincookies attribute. If you are using clustered servers, you want to specify this value as Yes, so that your cookies are readable across each server in your cluster. Each server in the cluster has a different domain, all of which are a subset of your master domain. Each server will probably have a domain name similar to server l.mydomain.com and server2.mydomain.com. By setting this value to Yes, you are setting a cookie for mydomain.com, and all subdomains of that domain are able to access the same cookies. You also set a cookie called cfmagic that ColdFusion implicitly checks to decide whether or not it should check for domain cookies. If you are using clustered servers and set this value to No, and then the user is moved from one server to another, for whatever reason, then that user will lose all of his or her cookies and, therefore, all of his or her client variables. If you are not using clustered servers, then you can set this value to No or leave it blank. No is the default value for setdomaincookie.
The next two attributes in the CFAPPLICATION tag define how our application is to react to client management. The clientmanagement attribute looks for a Yes or No value. Selecting Yes turns on client management, which means your application will have access to client variables. Selecting No turns off client management, which means the usage of client variables is not allowed in your application. If you do not plan to use client variables, you can leave this attribute out because the default is No.
The next tag attribute, clientstorage, tells the application where to store the client variables. There are three different options here. The default value is Registry, which tells the application to store client variables in the server's registry. The downside to storing client variables in the registry is that registry access tends to be single-threaded, and can cause a slowdown if you have a large number of users accessing the site. For administrators who prefer to keep tight control over their servers, there is a way through the ColdFusion administrator to change the default storage mechanism for client variables.
The other two options are Cookie or to specify a datasource. Choosing Cookie allows you to store client variables as cookies on the user's machine. Cookies can be a powerful mechanism for unlimited client storage, but this option still has its drawbacks. If the user's browser is set to disallow cookies, then the client variables will not work, as previously discussed. The last option, which is to store client variables in some ODBC datasource, is my preferred method. It does not violate the integrity of the server by writing values to the registry, nor does it threaten security for users who are afraid of the "dreadful" cookie.