Application.CFC Template Update

Someone asked me today when I was going to update my Application.cfc reference (linked to in the Guides pod to the left) for ColdFusion 8. I went ahead and did so. You can see the new guide here:

http://www.raymondcamden.com/enclosures/application.txt

You will notice I changed to a text file for this one. I always found it bothersome that when I copied from the PDF, I lost my tabs. Since I'm a bit anal retentive about tabbing, I figured a simple txt file would be better. Shoot, this whole PDF thing is probably just a fad anyway.

I also included comments in this template. I didn't do it before because - well - I wanted folks to have something they could just cut and paste into a new file (or into a CFEclipse Snippet). But I figured one line comments can't hurt. If folks think it is a mistake, let me know. Again the intent here is to serve as a template, not really a learning guide. You will notice that in the official docs, they forgot some of the items you can include. For example, the reference guide forgot customtagpaths and mappings. The dev guide has them - but forgot the other new This scope items like secureJSON. (I've logged bugs for both of these issues.)

Lastly - I've kept the CF7 version linked as well.

Archived Comments

Comment 1 by Andy Matthews posted on 11/6/2007 at 3:56 AM

And of course one DAY after I rewrite my custom CMS to use app.cfc.

:)

Thanks Ray...the tutes and assistance you give are always top notch. Appreciated.

Comment 2 by Raymond Camden posted on 11/6/2007 at 4:00 AM

I had to read "tutes" a few times to figure out you meant tutorials. ;)

Comment 3 by Jeff Fleitz posted on 11/6/2007 at 5:45 PM

Good timing for me Ray. I just updated to CF8 2 weeks ago and began the process of migrating my code to use App.cfc. I was actually on your site looking at the one for CF7 last night.

Thanks!

Comment 4 by Daniel Greenfeld posted on 11/6/2007 at 8:17 PM

Thanks for taking your documentation out of PDF. Text or ReStructuredText is the way to go. Easier for you to handle and it also means that we don't have to use a PDF reader/

Comment 5 by brian posted on 11/7/2007 at 4:58 AM

Do you think the delete onRequest stuff in onRequestStart for cfc calls should be in as standard? It can be a difficult one to pin down, especially when it causes problems with binding.

Comment 6 by Raymond Camden posted on 11/7/2007 at 6:55 AM

What delete?

Comment 7 by brian posted on 11/7/2007 at 1:43 PM

<cfif listlast(cgi.path_info,".") is "cfc">
<cfset StructDelete( THIS, "OnRequest" ) />
<cfset StructDelete(variables,"onRequest")/>
</cfif>

otherwise my cfselect binding to a cfc in the same directory doesn't work.

Comment 8 by Raymond Camden posted on 11/7/2007 at 7:30 PM

Ah. Hmm, good point. Thing is - I really want this to be a "no code" template, ie, no assumptions. I _did_ do some code inside onError.

Hmmmm. What do people think? What if I add an additional comment with very obvious warnings:

<!--- NOTE THAT THIS METHOD DISABLES CFC CALLS --->

And maybe I can link to an a blog entry on the method you described?

Comment 9 by brian posted on 11/7/2007 at 10:51 PM

I think that's a good idea. This 'feature' needs wider publicity, as someone approaching this afresh can use a 'standard' application.cfc with a standard binding example and have no clue why it's not working

Comment 10 by Justin Schier posted on 10/14/2008 at 4:04 AM

Ummm... I've been programming Coldfusion for 10 years, and I've been using your Application.cfc template for at least the last 3 or 4 in all my applications. Thanks so much for that!

BUT!

Today I was working on some Ajax calls direct to a CFC and they were returning a blank page. I could not figure out why for 2 hours until I found this page.

As soon as I put in Brian's code, it started working as expected. (THANK YOU BRIAN!)

What the F is up with having to do that?? Why does your template not work with direct calls to CFCs? I'm an advanced CF developer and you've got me on this one.

Anyway, it's not "very obvious" to me, sorry. I wish you would have put that comment in, as well as some kind of explanation WHY it disables CFC calls and HOW to enable them.

Thanks very much for all you do!!
Justin

Comment 11 by Raymond Camden posted on 10/14/2008 at 5:03 AM

Please check the template now. Nice and "loud" I would hope. :)

Comment 12 by Will posted on 3/13/2009 at 9:38 PM

So is it that using an INCLUDE to run the cfc that breaks it? Or will the cfc not even run unless you force invoke it through the onrequest. Let's say my onRequest was essentially empty, we run http://site/my.cfc?var1=1&var2=2 and my.cfc is setup for remote. If onRequest is present but empty, will it still run?

Comment 13 by Raymond Camden posted on 3/13/2009 at 9:48 PM

Hmm. I think it will break, but why not try it yourself and tell us. :)

Comment 14 by Will Broadhead posted on 3/14/2009 at 12:13 AM

Okay. I tried it out. Yes, it works fine. As long as your application.cfc/applicationOnStart isn't the driver (I let the index.cfm drive the content by pageid), it lets a direct cfc call go through fine, and thus, ajax calls should work fine. So it does seem to be the include call that breaks a cfc call. Which makes sense. I wouldn't really expect cfinclude to run a cfc.

It consumes the url vars as both url and argument input. I just output from onRequestStart and the called function to screen to test:

SIMPLE FUNCTION:
ffunction name="fn_TestGateway" access="remote" returntype="any" hint="TEST" >
<cfargument name='testytester'>
<HR/>fn_TestGateway HAS RUN CORRECTLY...<HR/>
<cfif isDefined('arguments.testytester')>ARGUMENT: <cfoutput>#arguments.testytester#</cfoutput><br /></cfif>
<cfif isDefined('url.testytester')>URL: <cfoutput>#URL.testytester#</cfoutput><br /></cfif>
</cffunction>

REQUEST:
http://mfi/_code/_application/_initializeApplicationVariables.cfc?method=fn_TestGateway&testytester=howdy

RESULT:
- in onRequestStart - x=123
fn_TestGateway HAS RUN CORRECTLY... ARGUMENT: howdy
URL: howdy

Comment 15 by Will Broadhead posted on 3/18/2009 at 5:06 AM

My apologies, Ben just set me straight. I was confusing onRequest with OnRequestStart. After reading the onRequest docs from Adobe, I see no reason I would ever want to tangle with it. And thus all the brouhaha about how to handle its use as it intercepts the main cfm/cfc call. So my whole post was moot. Thanks for your patience and understanding! :)

Comment 16 by Phil Williams posted on 7/30/2009 at 3:46 PM

Hi Ray,
I must be going blind but I can't find the link to the MX7 version of your template, could you post a link?

Thanks...

Phil

Comment 17 by Raymond Camden posted on 7/31/2009 at 8:23 AM
Comment 18 by Phil Williams posted on 7/31/2009 at 11:42 AM

Excellent, thanks Ray :)

On a side note, I've downloaded BlogCFC and found a couple of issues, where would be the best place to report them? Excellent application overall though...

Phil

Comment 19 by Raymond Camden posted on 8/2/2009 at 12:23 AM

I'd report the issues at the RIAForge project page:

http://blogcfc.riaforge.org

Comment 20 by Brian posted on 5/12/2010 at 12:15 AM

A question about onError: should the attribute "output" be true and not false so when you dump the arguments, they display? Or am i missing something?

Comment 21 by William Broadhead posted on 5/12/2010 at 1:46 AM

If you want the actual onError event to draw anything to the html output flow, yes, you need output on. Otherwise, if your onError event sends an email, calls another function, passes its resulting values to a a function that handles your errorDisplay (which should have output turned on so it can display), then you can leave the output set to false

Comment 22 by snake posted on 6/22/2012 at 6:19 PM

FYI, the link no longer works.

Comment 23 by Raymond Camden posted on 6/22/2012 at 7:11 PM

Fixed. Note though that this blog entry is almost 5 years old and the code is WAY out of date.