Extending The Application.cfc ColdFusion Framework Component With A Relative-Path Proxy

Yesterday, I demonstrated how to use a ColdFusion custom tag in order to define an Application.cfc body such that you could extend the current Application.cfc instance with a base Application.cfc using a relative path. In the comments to that post, Walter Seethaler dropped a knowledge bomb on us, explaining that you could accomplish the same thing by simply extending a local proxy that, itself, CFInclude'd the root Application.cfc. This might just be brilliant!

To quickly outline this approach, imagine that you have an Application.cfc in a sub-directory that needs to extend a root Application.cfc; but, you don't know what the web-root relevant class path for that root Application.cfc is. To use a relative path (relative to the sub-directory Application.cfc), you can extend a local proxy:

This local proxy (RootProxy.cfc) then does nothing more than include the root Application.cfc using a relative path:

Here, we are taking advantage of the fact that CFInclude works with relative paths and that one ColdFusion component can be CFIncluded into another ColdFusion component. In the end, we are using a relative path to extend a ColdFusion component.

Now, in the comments, Walter mentioned that there were some issues with object creation during the CFInclude process, so I wanted to make sure that I tested this thoroughly. Here is my testing directory structure:

./
./Application.cfc
./Test.cfc
./index.cfm
./sub/
./sub/Application.cfc
./sub/RootApplication.cfc
./sub/index.cfm

This time, you'll notice that there is a Test.cfc ColdFusion component in the root directory. There is nothing in this component (save a CFComponent tag); it is there simply to determine whether or not calls to the createObject() function will succeed or fail during various aspects of the page load.

Ok, let's dive into the code. First, let's take a look at our root-level Application.cfc file:

Application.cfc (In The Root-Directory)

As you can see, we're going to be checking a number of things:

• What does getCurrentTemplatePath() give us in the pseudo constructor.
• Is createObject() relative to the current template in the pseudo constructor.
• Is createObject() relative to the current template in the onRequestStart() event handler.
• What does the THIS object look like within the onRequest() event handler.

Normally, I would execute the index.cfm in the root and show you the output; but, let's face it - when we're in the root of the application, there's nothing special going on. As such, let's proceed directly to the Application.cfc located within our sub-directory:

Application.cfc (In The Sub-Directory)

In this Application.cfc ColdFusion component, we are testing the same functionality, roughly; how things work in the pseudo constructor vs. the event handlers. You'll notice, however, that this component extends the sub-directory-based RootApplication.cfc component. And, as I described above, this proxy does nothing more than CFInclude the root Application.cfc:

RootApplication.cfc (In The Sub-Directory)

Ok, now we need to pull all of this together into a test. In our sub-directory, we have an index.cfm file which outputs the Application and request scopes, followed by a new instance of the local Application.cfc component. If you look back up in the root-level Application.cfc, however, you'll see in the onRequest() event handler that we also start off by CFDump'ing out the current THIS configuration (of the current request):

Index.cfm (In The Sub-Directory)

When we run the above page, we get the following output. Since there are a lot of interesting things going on here, I have marked up the CFDump output with numbers, which I will then explain below.

In the above output, there is a horizontal line. The Application.cfc instance above the horizontal line is the THIS scope of the Application.cfc that has been implicitly instantiated by the ColdFusion application server as a way to process the incoming page request. The Application.cfc instance below the horizontal line is a completely new instance that we manually instantiate and output. I make sure to draw this distinction because these two modes of instantiation result in different behaviors.

Ok, let's take a look at the callouts in the above output:

1. We can see that calls to the getCurrentTemplatePath() function return the appropriate paths. The root Application.cfc reports as the root version and the sub Application.cfc reports as the sub version.
2. Within the sub-directory Application.cfc pseudo constructor, we could not create an instance of our root-directory Test.cfc component. This indicates that the pseudo constructor of the sub-directory Application.cfc executes relative to the sub-directory (and therefore cannot locate the Test.cfc class definition that resides in the directory above).
3. In addition to #2, we also could not instantiate Test.cfc from within the pseudo constructor of our extended root-directory Application.cfc. Since the root Application.cfc is in the same directory as the Test.cfc component, this indicated that the pseudo constructor of the base Application.cfc (that we are extending) executes relative to the sub-directory.
4. If you look at the code, you'll see that our sub-directory Application.cfc onRequestStart() event handler invokes the super-scoped onRequestStart() event handler. The use of "super" in this case allows us to invoke the onRequestStart() event handler defined within our root-directory Application.cfc. From the CFDump, you can see that we were able to instantiate our Test.cfc component. This indicates that the event handlers of our super component execute relative to the root-directory even when invoked from within our sub-directory.
5. The event handlers within the sub-directory execute relative to the sub-directory (this is the expected behavior) and therefore, cannot instantiate the Test.cfc component located within the parent directory.
6. This is from the instance of the sub-directory Application.cfc that we instantiated manually. You'll notice that when instantiated manually, we were able to create an instance of our Test.cfc from within the pseudo constructor of our base Application.cfc. This is the opposite of what we found in #3. It appears that the context of the pseudo constructor of the base component changes depending on the explicit vs. implicit nature of instantiation.

Another thing that I noticed (but did not show in the testing) was that within the pseudo constructor of the extended-by-CFInclude Application.cfc, there are no methods in either the THIS scope or the VARIABLES. Typically, you can use local methods within the pseudo constructor; but, not in the extended version - those methods are not available until within the event handlers.

NOTE: You could use unscoped methods (ie. no THIS or VARIABLES prefix); but, they still execute relative to the sub-directory.

So, there's a lot of stuff going on here; but, this totally works if you follow the one main caveat:

Don't do anything within your pseudo constructor.

Of course, you still need to define the application settings (ie. this.name, this.applicationTimeout, etc.) in the pseudo constructor; but, don't do any real file-based logic within your pseudo constructor such as trying to load component instances.

This might seem like a big limitation; but, in my experience, it's not really. The ColdFusion application framework provides hooks to the life-cycle of the page request by giving you event handlers. You really shouldn't need to go outside of these event handlers to initialize your application (too much). I know people who have some requirement to load template-specific DSN values in the pseudo constructor or boot up ColdSpring instances; but, I still don't fully understand these requirements, so I can't speak to them.

We've done a lot of exploration of the Application.cfc ColdFusion application framework component over the last few days. There's definitely a lot to absorb here; and, I'm sure the exploration is far from comprehensive. A huge thanks to Walter for bringing this particular approach to light.

You Might Also Be Interested In: