Handling the "big picture" application flow in ColdFusion is extremely easy, as a large part of it occurs directly in your application's Application.cfc file. Getting a handle on what's going on, in an MSOC app or any other app, is a matter of managing that application flow effectively. If you have a solid understanding of the event handlers available to you, then you can really begin to see the power behind ColdFusion's application framework.

The ColdFusion Application Framework consists primarily of a single file, Application.cfc. When a request is made, ColdFusion will first look for an Application.cfc in the directory of the template requested. If one is not found, it will then traverse up each successive directory until it does find one, all the way up to your drive root if necessary. Once found, that is the application applied to that template request. This means that your Application.cfc file doesn't even need to be in the same directory as your site code. The Application.cfc can include several predefined methods that will automatically fire during key parts of application processing. We'll go more in depth of each set on future posts, but the gist of it is that there are methods that fire on the first request to an application, and when an application times out, when a new user session starts, and when it times out, and so on. This allows us to finely tailor how certain situations are handled during these important states of application life cycle. And, with careful planning, we can finely tune what our application memory footprint will do during that life cycle (which is highly important for an MSOC app) by carefully managing variables in their appropriate scopes.

A Word On Scopes

Back in the day, when the application framework was managed by Application.cfm, many developers spent a lot of time locking access to many persistent variables. This was a necessity, to one user's interactions from corrupting the data of another user's request. With Application.cfc, this headache is largely eliminated, because the ColdFusion server handles this locking for you during specific event processing. Here is a list of a some different scopes available for our use, and the event handlers that are associated with them in the application framework:

  • APPLICATION - A scope to place variables that are available throughout the life of an active application.
    • onApplicationStart
    • onApplicationEnd
  • SESSION - A scope to place variables that are available throughout the life of a specific user session, and only for that user session.
    • onSessionStart
    • onSessionEnd
  • REQUEST - A scope to place variables that are available throughout the life of a specific request, and only within that request.
    • onRequestStart
    • onCFCRequest
    • onRequest
    • onRequestEnd

Now, this isn't to say that you should never lock variable access. When operating within one scope's event handlers and accessing a different persistent scope, it is always a good idea to lock access to that foreign scope, especially when writing to that foreign scope. These scopes are the primary focus of these event handlers, but there are four other scopes to consider when working inside Application.cfc, just as in any other CFC:

  • LOCAL - A function specific scope, whose variables are created, and only available, inside the function.
  • ARGUMENTS - A function specific scope of variables passed into the function.
  • VARIABLES - A CFC global variable scope. Variables in this scope are available throughout the entire CFC, and can be accessed and changed at any point. Use carefully.
  • THIS - This too is a CFC global variable scope, though it's values are typically publically available via an outside call on the object. (Application.cfc usage may be the exception, as you don't typically directly access Application.cfc as an object.)

In the case of normal CFC development, you would not want to access any persistent scope directly, working strictly with these last four scopes. If you needed access to a variable in the APPLICATION, SESSION, or REQUEST scopes (or even URL, CGI, FORM and CLIENT scopes), you would typically pass those value in to a CFC method as an argument. The Application.cfc is the one true exception to that rule.

I hope that someone has found this little primer on the Application.cfc helpful. In the coming posts we'll discuss the application event handlers in sets, giving some suggestions on possible usages in each. As always, if you have any comments/suggestions/questions, please use the comment form or Contact form below.