Application.cfm vs. Application.cfc

Application.cfm vs. Application.cfc

Many people who are using ColdFusion MX +, are unaware of the benefits of the Application.cfc pages, so have not used them. I will endeavor to explain how an Application.cfc page can be a tremendous boon to any Enterprise level website.

Imagine this. Everytime you open a page on your website, the Application page is run.

On the Application.cfm page, each line is run in sequence every time. If you load many APPLICATION variables or SESSION variables or other ‘environment’ variables, then you are recreating them, every time you open a page on the server. This is a lot of work for the CF server and can cause slowages on even the smallest websites.

On the Application.cfm page, only the code that is necessary is run.
Examples:
These 3 sections are common sections in an Application.cfc page.

1. onApplicationStart
2. onSesssionStart
3. onRequestStart

The ‘application start’ is the first time an application (the website) is run on the server, or after it has timed out. Therefore the code in the onApplicationStart section will only run at the time the website runs for the first time on the server, or after a timeout. (or reboot of the server)

The ‘session start’ is the first time a unique web browser visits an application (the website), or after the session cookies have been erased. Therefore the code in the onSessionStart section will only run at the time a web browser starts its progress through your site.

The ‘request start’ is every time a page is called on the web server. Therefore the code in the onRequestStart will always run when a new page is requested (or a page is ‘refreshed’)

There are many possible sections on the ‘Application.cfc’ page, but the above are the most common. Hopefully you can see how a cfc can severly reduce the stress on a coldfusion server.

Let’s say that you have large language files that you load into the system in order to easily change from one language to another. In the past you might have called these variables lang.welcome = ‘Welcome’. Well, you could place these language files in the application.cfc – onApplicationStart section, and only load them when the application starts. This would reduce the overhead of lines of code that was needed to start each page.
You could make that into a structure:
Application.lang[‘en’].welcome = ‘Welcome’;
Then in the onRequestStart you can change the ‘session.lang’ variable based on the most recent choice of the user, and call each variable in this manner.
Application.lang[session.lang].welcome.

This would make it so that you would only load the multitude of line of code that describe the language variables into the application scope once, but be able to call the values on each page load.

With an Application.cfm page, you would have to load each language file every single time you loaded the page.

The benefits don’t stop there. There are a few additional ‘sections’ of an Application.cfc page that can benefit ColdFusion developers.

onError is used to capture page errors and deal with them in any fashion that the developer sees fit. This is a huge advance over the limitations of the <cferror> tag.

The onMissingTemplate section can be used to capture requests for ‘.cfm’ pages that don’t exist (or no longer exist) on your site. I have used this in the past to show a brief ‘page not found’ error to the user, then display a search result of possible matches to what the user ‘might’ have been looking for. Certainly a whole lot better than the static ‘dead end’ page that apache or IIS want to show the user.

I encourage you to have some fun testing and experimenting with the different sections of the Application.cfc page, only a few of the sections are listed here.