Introduction to the Application.cfc Object and Application Variables in ColdFusion 9

Exclusive offer: get 50% off this eBook here
ColdFusion 9 Developer Tutorial

ColdFusion 9 Developer Tutorial — Save 50%

Create robust professional web applications with ColdFusion

$29.99    $15.00
by John Farrar | July 2010 | Web Development

There is a huge difference between a web application and a dynamic web page. Web applications persist basic information, so we can create things such as shopping carts, user authentication (login and logout), and much more. HTML helps us to click through pages with links. In this two-part article series, we will learn how we can use web server memory to create engaging and interactive web applications by using variable scopes.

In this article by John Farrar, author of ColdFusion 9 Developer Tutorial, we will have a look at the following topics:

  • The life expectancy for various types of information. This affects the system memory and the place where different information is stored.
  • The Application.cfc object class—the cornerstone of ColdFusion applications.

(For more resources on ColdFusion, see here.)

Life span

Each of our shared scopes has a life span. They come into existence at a given point, and cease to exist at a predictable point. Learning to recognize these points is very important. It is also the first aspect of "Scope".

The request scope is created when a request is made to your ColdFusion server from any source. This could either be a web browser, or any type of web application that can make an HTTP request to your server. Any variable placed into the request structure persists until the request processing is complete.

Variable persistence is the property of data remaining available for a set period of time. Without persistence, we would have to make information last by passing all the information from one web page to another, in all forms and in all links. You may have heard people say that web pages are stateless. If you have passed all the information into the browser, they would be closer to stateful applications, but would be difficult to manage. In this article, we will learn how to create a stateful web application. Here is a chart of the "life spans" of the key scopes:

Scope Begins Ends
Request Begins when a server receives a request from any source.
Created before any session or an application is created.
Ends when the processing for this request is complete.
Ending has nothing to do with the end of applications or sessions.
Application Begins before a session but after the request.
Begins only when an Application.cfc file is first run with the current unique application name, or when the <cfapplication> tag is called in older code CF applications.
Ends when the amount of time since a request is greater than the expiration time set for the application.
Session Begins after an application is created.
Created inside the same sources as the application.
Ends when the amount of time since a request is greater than the expiration time set for the session.
Client Begins when a unique visitor first visits the server. If you want them to expire, you can store client variables in encrypted cookies. Cookies have limited storage space and are not always available.

We will be discussing the scopes in more detail later in this article series.

All the scopes, except the client scope, expire if you shut down your server. When we close our browser window or reboot the client side, a session does not come to an end, but our connectivity to that particular session scope ends. The information and resources for storing that session are held until the session expires. Then, when connecting the server starts a new session and we are unable to reconnect to the former session.

Introducing the Application.cfc object

The first thing we need to do is to understand how this application page is called. When a .cfm or .cfc file is called, the server looks for an Application.cfc file in the current directory where the web page is being called from. It also looks for an Application.cfm file. We do not create an application or session scope with the .cfm version because .cfc provides many advantages and is much more powerful than the .cfm version. It provides better encapsulation and code reuse. If the application file is found, ColdFusion runs it. If the file is not found, then it moves up one directory towards the sever root directory in order to search for an Application.cfc file. The search stops either when a file is found, or once it reaches the root directory and a file is not found.

There are several methods in the Application.cfc file. It is worth noting that this file does not exist by default, the developer must create it. The following table gives the method names and the details as to when those methods are called:

Method name When a method is called
onApplicationEnd The application ends; the application times out.
onApplicationStart The application first starts: the first request for a page is processed or the first CFC method is invoked by an event gateway instance, a web service, or Macromedia Flash Remoting CFC.
onCFCRequest HTTP or AMF (remote special Flash) calls.
onError An exception occurs that is not caught by a try or catch block.
onMissingTemplate ColdFusion receives a request for a non-existent page.
onRequest The onRequestStart() method finishes(this method can filter request contents).
onRequestEnd All pages in the request have been processed.
onRequestStart A request starts.
onSessionEnd A session ends.
onSessionStart A session starts.
onServerStart A ColdFusion server starts.

When the Application.cfc file runs for the first time, these methods are called in the order as shown in the following diagram. The request variable scope is available at all times. Yet, to make the code flow right, the designers of this object made sure of the order in which the server runs the code. You will also find that for technical reasons, there are some issues that arise when we use the onRequest() method. Therefore, we will not be using this method.

The steps in the previous screenshot are explained as follows:

  1. Browser Request: The browser sends a request to the server. The server passes the processing to the Application.cfc file, if it exists. It skips the step if it does not exist. The Application.cfc file has methods that execute if they exist too. The first method is onApplicationStart(). This executes on the basis of the application name. If the unique named application is not currently running on the server, then this method is called.
  2. Application Start: The next thing that Application.cfc does is to check if the request to the server is a pre-existing application. If the request is to an application which has not started, then it calls the onApplicationStart() method, if the method exists.
  3. Session Start: On every request to the server, if the onSessionStart() method exists, then it is called at this particular point in the processing.
  4. Request Start: On every request to the server, if the onRequestStart() method exists, then it is called at this particular point in the processing.
    1. OnRequest: This step normally occurs after the onRequestStart() method. If the onRequest() method was used, then by default it prevented the calling of CFCs. We do not say that it is always wrong to use this method. However, we will avoid it as much as possible.
  5. Requested Page: Now, the actual page requested is called and processed.
  6. Request End: After the requested page is processed, the control is passed back to the onRequestEnd() method, if it exists in Application.cfc.
    • return response to browser: This is the point when ColdFusion has completed its work of processing information to respond to the browser request. At this point, you could either send HTML to the browser, a redirect, or any other response.
    1. Session End: The onSessionEnd() method is called if the method exists but only when the time since the user has last made a request to the server is less than the time for the session timeout.
    2. Application End: The onApplicationEnd() method is called if it exists when the time since the last request was received by the server is greater than the timeout for the application.

The application and session scopes have already been created on the server and they do not need to be reinitialized. Once the application is created and other requests are made to the server, the following methods are called with each request:

  • onRequestStart()
  • onRequest()
  • onRequestEnd()

In previous versions of ColdFusion, when the onRequest() method of the Application.cfc was called, it blocked CFCs from operating correctly. You may see some fancy code in older frameworks that check if the current request is calling a CFC. They would then delete the onRequest() method for that request. Now there is a new method called onCFCRequest(). If you need backwards capability to previous versions of ColdFusion, then you would delete the onRequest() method. You can use either of these approaches depending on whether you need the code to run on prior versions of ColdFusion. The onCFCRequest() method will execute at the same point as the onRequest() method in the previous examples. You can add this code in or not depending on your own preferences. The previous example still operates as expected if you leave the method out.

The OnRequestEnd.cfm side of using Application.cfm based page calls does not execute if the page runs a <cflocation> tag before the OnRequestEnd.cfm is run. It is also not a part of Application.cfc based applications and was intended for use with Application.cfm in older versions of ColdFusion.

Here is a representation of the complete process that is less granular. We can see that the application behaves just as it did in the earlier illustration; we just do not go into explicit detail about every method that is called internally. We also see that the requested page can call additional code segments. These code segments can be a CFC, a custom tag, or any included page. Those pages can also include other pages, so that they create a proper hierarchy of functionality. Always try to make sure that functionality is layered, so the separation of layers provides a structured and simpler approach to creation, maintenance, and long-term support for your web applications.

The variables set in Application.cfc can be modified before the requested page is called, and even later. Let us say for example, you want to record the time at which the session was last hit. You could choose to set a variable, <cfset session._stat.lasthit = now()>. This could be set either at the beginning of a request, or at the end. Here, the question is where you would put this function. At first, you might think that you would add this function to the OnSessionStart() method or OnSessionEnd() method. This would cause an issue because these two methods are only called when a session has begun or when it has come to an end. You would actually put the code into the OnRequestStart() or OnRequestEnd() code segment of the Application.cfc file for the function to work properly. The request methods are called with every server request. We will have a complete Application.cfc to use as a model for creating our own variations in future projects. Remember to place the code in the right place and test your code using CFDump or by some other means to make sure it works when creating changes.

ColdFusion 9 Developer Tutorial Create robust professional web applications with ColdFusion
Published: July 2010
eBook Price: $29.99
Book Price: $49.99
See more
Select your format and quantity:

(For more resources on ColdFusion, see here.)

Application variables

There are some application variables that determine the behavior of an application. Inside the application, all the variables are stored inside this scope. The scope refers to the location where the .cfc file is found. Generally, this is not considered a good practice because the variables are not protected from outside the object. In Application.cfc, this is not an issue because there is no code to create an instance of the object for reuse. The following are the application scoped variables in Appliation.cfc that you will use.

Variable Default Description
name no name This is the application name. If you do not set this variable, or set it to the empty string, your CFC applies to the unnamed application scope, which is the ColdFusion MX J2EE servlet context.
applicationTimeout Administrator value Life span, as the actual number of days of the application, including all Application scope variables. Use the CFML CreateTimeSpan function to generate this variable's value.
clientManagement Administrator value Checks whether the application supports Client scope variables.
clientStorage Administrator value Client variables are stored here. Client variables can be cookie, registry, or the name of a data source.
customTagPaths Administrator value Contains ColdFusion custom tag paths. To use this variable, set the custom tag path in the Administrator EXTENSIONS | Custom Tag Paths page. The settings that you define here take precedence over the custom tag paths defined in the Administrator SERVER SETTINGS | Mappings page for the current application.
debugIPAddress   Overrides the default administrator settings. It does not report compile-time exceptions.
enableRobustException   Overrides the default administrator settings. It does not report compile-time exceptions.
googleMapKey   The Google Maps API key required to embed Google Maps in your web pages.
datasource   Name of the data source from which the query retrieves data.
loginStorage Cookie Whether to store login information in the Cookie scope, or the Session scope.
mappings Administrator value A structure that contains ColdFusion mappings. Each element in the structure consists of a key and a value. The logical path is the key and the absolute path is the value. To use this value, select the Enable Per App Settings option in the Administrator SERVER SETTINGS | Settings page.
serverSideFormValidation yes Whether to store login information in the Cookie scope or the Session scope.
sessionManagement no Checks whether the application supports Session scope variables.
sessionTimeout Administrator value Life span, as the actual number of days, of the user session, including all session variables. Use the CFML CreateTimeSpan function to generate this variable's value.
setClientCookies true Whether to send CFID and CFTOKEN cookies to the client browser.
setDomainCookies false Whether to set CFID and CFTOKEN cookies for a domain (not just for a host).
scriptProtect Administrator value Whether to protect variables from cross-site scripting attacks.
secureJSON Administrator value A Boolean value that specifies whether to add a security prefix to a value that the ColdFusion function returns in JSON-format, in response to a remote call. The default value is the value of the Prefix serialized JSON setting in the Administrator SERVER SETTINGS | Settings page (which defaults to false).You can override this value in the <cffunction> tag.
secureJSONPrefix Administrator value The security prefix to the value that a ColdFusion function returns in JSON-format, in response to a remote call, if the secureJSON setting is true.The default value is the value of the Prefix serialized JSON setting in the Administrator SERVER SETTINGS | Settings page (which defaults to //,the JavaScript comment character).
smtpServerSettings

 

A struct that contains the following values: server, username, and password. If no value is specified, takes the value of the administrator.
timeout   The lifespan. Timeout set using <cfsetting requesttimeout=""> overrides the timeout in Application.cfc using this.timeout-"".
welcomeFileList

 

A comma-delimited list of names of the files. It tells ColdFusion not to call the onMissingTemplate() method if the files are not found. Use this variable to prevent ColdFusion from invoking the onMissingTemplate() handler if all of the following items are true:

  • Your web server (for example, web.xml file) has a welcome file list with the CFML pages such as index.cfm that it tries to run if a URL specifies the path ending in a directory.
  • The web server sends a request for CFML pages; it is the welcome list to ColdFusion without determining that the page exists.
  • You have to support "directory browsing" in directories that do not have any of the files on the welcome file list.
  • You specify this variable only if the Application.cfc file specifies an onMissingTemplate() handler. It should contain the same list of files as your web.xml welcome file list.

Note that you do not need to use the welcomeFileList variable with web servers, such as Apache. You also need to use the welcomeFileList variable with the most integrated web and application servers, such as integrated ColdFusion or JRun web server.

The following is an example of setting some application variables as might be done in an Application.cfc file:

<cfscript>
this.name = "ApplicationName1";
this.applicationTimeout = createTimeSpan(0,2,0,0);
this.clientManagement = true;
this.clientStorage = "cookie;
this.loginStorage = "session";
this.sessionManagement = true;
this.sessionTimeout = createTimeSpan(0,0,20,0);
this.setClientCookies = true;
this.setDomainCookies = false;
this.scriptProtect = false;
</cfscript>

This is just an example as to how we could set these variables. There is never a special way to do this. For each site, we should consider a particular format or method that makes the most sense for how we want these settings. The type of work done by some people may mean that they end up using the same settings all the time. That is also fine, as long as, we remember to think about getting the settings right.

Summary

In this article we covered the life expectancy for various types of information, Application.cfc object class and the application variables. In the next article we will see Application, Session, and Request Scope in ColdFusion 9


Further resources on this subject:


ColdFusion 9 Developer Tutorial Create robust professional web applications with ColdFusion
Published: July 2010
eBook Price: $29.99
Book Price: $49.99
See more
Select your format and quantity:

About the Author :


John Farrar

John started working with computer programming around 1977. He has had the opportunity to work on projects used by Apple, Blue Cross, Brunswick Recreation, Casio, GVSU, Johnson Controls, Sprint, and many others. This history covers over 30 years of knowledge and experience in the industry.

He started doing web development over 10 years ago. In the early days of the Web ColdFusion stood out to him not just as a way to make web pages into web applications but as a maturing solid platform good for the developer, site owner, and end users. He started at version 4.5 and has been enjoying each version upgrade more and more.

John owns a company called SOSensible. His company does work for large companies but has a special focus on also making sure technology is approachable beyond the enterprise. They have developed a number of Open Source solutions including COOP. COOP is a mix of Custom Tags and CFCs that provides structure while keeping development simpler. It demonstrates his love for the things that make ColdFusion/CFML a delightful language to build websites.

He has spoken at national and regional conferences, online meetings, and area user group meetings. He is also an Adobe User Group manager. John knows that community is a viable and productive tool to build developers and the companies they serve. He has learned much from great resources in the community including bloggers, books, conferences, and resources to great in number to mention here. He blogs at sosensible.com for the community.

Contact John Farrar

Books From Packt


Microsoft Silverlight 4 Data and Services Cookbook
Microsoft Silverlight 4 Data and Services Cookbook

JavaFX 1.2 Application Development Cookbook
JavaFX 1.2 Application Development Cookbook

Ext JS 3.0 Cookbook
Ext JS 3.0 Cookbook

NetBeans Platform 6.9 Developer's Guide
NetBeans Platform 6.9 Developer's Guide

YUI 2.8: Learning the Library
YUI 2.8: Learning the Library

ASP.NET 3.5 Application Architecture and Design
ASP.NET 3.5 Application Architecture and Design

Oracle JRockit: The Definitive Guide
Oracle JRockit: The Definitive Guide

MooTools 1.2 Beginner's Guide
MooTools 1.2 Beginner's Guide


No votes yet
Very Good Article by
Hi , Thanks For Providing Good Article.
Re: Order of Application, Request & Session instantiation by
Hey John. Have just the article further on and can see (from the diagram) that you're saying that onApplicationStart() is called before onRequestStart(), which is slightly at odds with the first table in the article, which says: Request: Begins when a server receives a request from any source. Created before any session or an application is created. Regards, Aidan
Order of Application, Request & Session instantiation by
Hi John Good article, thanks. BTW, putting this code (below) in an Application.cfc file, restarting the ColdFusion service and calling a blank .cfm file in the browser would seem to contradict your assertion of the order in which the scopes are processed. The order in both CF8 and CF9 appears to be Application, Session and then Request. The results are: OnApplicationStart: 1287577769245 YES : NO : NO OnSessionStart: 1287577769261 YES : YES : NO OnRequestStart: 1287577769261 YES : YES : YES ============ Start Application.cfc ============

OnApplicationStart: #getTickCount()#
#isDefined("application.test")# : #isDefined("session.test")# : #isDefined("request.test")#

OnApplicationStart: #getTickCount()#
#isDefined("application.test")# : #isDefined("session.test")# : #isDefined("request.test")#

OnApplicationStart: #getTickCount()#
#isDefined("application.test")# : #isDefined("session.test")# : #isDefined("request.test")#

============= End Application.cfc ============= Regards, Aidan

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
n
3
S
3
2
C
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software