I'm a really big fan of application.cfc. I like the organization and the fact that I can define certain events and variables based on the various events that happen when my application is used.

To me it's much cleaner and organized to to do this:

Then this:

Just knowing that foo will only be set if my application starts and that I don't have to worry about whether or not it may already exist makes me happy.

That being said I realized recently that I personally have not been taking full advantage of much of the power of the various functions available. For example, I often take advantage of onRequestStart to do user authentication, page logging, etc - but I rarely use onRequest. So what is a good use case for onRequest? Well lets start with a simple skeleton function showing the structure of onRequest. This is copied from Ray Camden's Application.cfc reference which I highly recommend you get a copy of and use as a skeleton for your applications that use application.cfc.

Pretty simple eh? The function accepts one argument - the page being requested. So what else can you do in onRequest? Well notice that the page that is passed is then included back into the function. How about doing something before that request? Like what? Well setting variables is a possibility - but may be unlikely. Application wide variables should be set in onApplicationStart. Variables specific to a template would be better off being set in the template itself to avoid confusion and hard to read code. What we could do is repetitive tasks that we'd rather not even care about seeing happen on an individual template basis. Like what? Well lately I've been using onRequest to parse search engine safe (SES) URL's. I will normally have a component of utils/udf's that I create in the application scope. One of the functions may be something like this parseSES function (borrowed once again from Ray).

So my onRequest would look something like this (assuming the function above was included in a component created in the application scope called utils).

Simple but effective. Now I do not have to worry about calling that function on every template. It's just done. I can now assume that every template will correctly interpret a URL like http://foooooo.com/todd/sharp as url.todd = 'sharp'. You could also take advantage of onRequest to cfinclude a UDF library, etc.