About a week ago (who has time to keep up with this stuff?) Ben Nadel wrote an excellent article about Setting custom Application.cfc settings based on the server environment, which I think is great supplemental reading to my article about Setting environment-specific Application.cfm settings. As Ben points out, the important distinction is that his internal function is only setting up the Application.cfc settings, not Application variables; while the goal of my post was to aid in determining which values to set for your Application variables. We differ on the fact that he thinks you should avoid having configuration files outside of the web root, while I think they are just fine as long as you code appropriately. In my example, if the file is not found, or the contents don't match any of the expected contents, then we assume we are in production. This may cause some frustration while configuring new development, test, QA, or staging environments; if you forget that the file has to exist and have appropriate contents, but ensures that unless someone deliberately sets a non-production value in the config file, production will always be right.

I am eagerly awaiting this year's update to the list of things that have happened since the announcement of Duke Nukem Forever, and if I may be allowed to conjecture a bit, I think we can add CFMenuCal alpha2 to the list. I'm planning to have three surprises, one of which is a new name! At this point, there are very few people who know what the new name will be, and even less who know what the other major change is. If you are on that list, consider yourself quite privileged. And if you do know? Please don't spill the beans! I hope to have the changes done within a couple of weeks, but that depends on my availability. This time of year always seems to be packed with weekend trips, and when we do have a weekend at home, it's spent doing housework. But I promise that aside from my job and my family, this is not only my top priority, but the thing I am most interested in, which means it should be getting a fair amount of attention. Now that I have a proper name for the project, if anyone is interested in designing a logo for it, please get in touch with me via Instant Messenger or email, or heck, even just leave a comment and I'll contact you!

I am admittedly behind the times when it comes to knowing how to code and use AJAX; I simply haven't had time to learn it. However, the need came up today to do some AJAX processing, and instead of spending days researching and learning how to do it properly, I just planned out and executed what I'm lovingly calling "Poor Man's Ajax." It took me about 2 hours, and it was a piece of cake. Of course, it would have been even easier with the new AJAX framework built into CF8, but alas, my client isn't quite ready to upgrade. A bit of semantics: While my solution doesn't make use of XML, neither does "AJAX" that uses JSON instead of XML to pass data back and forth. I don't think there is any reason you can't call what I'm doing AJAX: It's asynchronous, is controlled by JavaScript, and instead of XML or JSON, it simply uses embedded JavaScript in a hidden iFrame. The problem: Once a JavaScript event is fired, I need to do a SELECT from my database, and use that value to inject some new code into a DIV on my page. The solution: To make things asynchronous, I added a hidden iFrame to my page, whose SRC attribute I will change with JavaScript when my event is triggered: [viewcode] src="poor_mans_ajax.txt" showsyntax=no lines=1 geshi=html[/viewcode] In order to accept some data back from the asynchronous processing, I have to create a callback function: [viewcode] src="poor_mans_ajax.txt" showsyntax=no lines=2-4 geshi=javascript[/viewcode] And we have to trigger the request when an event occurs, which in my case was handled by a Flash movie. In order to initiate my request, all I have to do is change the SRC attribute of the iFrame: [viewcode] src="poor_mans_ajax.txt" showsyntax=no lines=5-7 geshi=javascript[/viewcode] After we change the SRC attribute of the iFrame, the request has begun! From here on out, it's out of our hands. The CFML page requested in the iFrame will take care of any data processing, and then send its result back to the specified callback function. Remember that all I wanted to do was a SELECT and return the value: [viewcode] src="poor_mans_ajax.txt" showsyntax=no lines=8-16 geshi=cfm[/viewcode] Conclusion: There are a few important things to note here; particularly:

• This page was used as part of a company intranet, where security is less of a concern, as the user base is limited and should be trusted to some degree. On a public facing site, you should check the validity of anything sent into the iFrame (via its query string), including the name of the callback function; and use CFQUERYPARAM in the query.
• Though I didn't test it, I believe that you can only pass simple values (strings and numbers) between pages in this fashion. However, it would be fairly easy to create a struct or array in JavaScript (inside your iFrame page), dynamically fill in its content with your CF code, and then use JSON to convert it to a string, pass it back, and then convert it back to a JavaScript object. Depending on your situation, you may even be able to use WDDX to serialize the data you want to pass back and forth.
• Notice that I defaulted my callback function variable to "void" in ajaxProcessor.cfm. In case we forget to specify a callback, nothing will happen, including throwing a JavaScript error.