CreateObject() Proxy Via ColdFusion Custom Tag
I just want to start off by saying that this idea was not mine. I have to give complete credit to Jeff Sanders who contacted me with this suggestion. I happen to think it's a really neat idea.
This idea has to do with the problem of creating ColdFusion components in parallel or parent directories without the use of mapped paths. A while back, I discussed getting around this idea by including a ColdFusion function into the Application.cfc/cfm file. This would create a mixin that leveraged the fact that ColdFusion component paths are relative the executing template, not the compiled page.
This worked, but the fact that it used a mixin always seemed a little less than elegant. Jeff Sanders came up with the idea to take this concept and use a ColdFusion custom tag, rather than a mixin, that could be used from anywhere in the application. To explain, let's use this sample directory structure:
./root/
./root/cfc/
./root/www/
In this structure, our ColdFusion components are going to be stored in the CFC folder; our website is going to be stored in the www folder. In this kind of a scenario, it would ordinarily be impossible to instantiate a component in the CFC directory from a file within the www directory without a mapped path or a mixin. To create a more elegant and portable solution, we can use a ColdFusion custom tag that lives in the root directory:
./root/createcfc.cfm
The CreateCFC.cfm ColdFusion custom tag is extremely simple and acts purely as a proxy to ColdFusion's CreateObject() method:
<!--- Kill extra output. --->
<cfsilent>
<!--- Param tag attributes. --->
<cfparam
name="ATTRIBUTES.Component"
type="string"
/>
<cfparam
name="ATTRIBUTES.ReturnVariable"
type="variablename"
/>
<!---
Create the ColdFusion component and store it into the
requested caller variable.
--->
<cfset "CALLER.#ATTRIBUTES.ReturnVariable#" = CreateObject(
"component",
ATTRIBUTES.Component
) />
<!--- Exit out of tag. --->
<cfexit method="exittag" />
</cfsilent>
As you can see, all it takes is the root-relative path to the target component and the return variable into which the instantiated CFC will be stored.
This tag is meant to be invoked using a CFModule tag in which you can supply the path to the target template:
<!---
Create CFC in parallel directory using ColdFusion
custom tag module.
--->
<cfmodule
template="../createcfc.cfm"
component="cfc.Test"
returnvariable="REQUEST.Test"
/>
<!--- Output the Test component message. --->
<cfoutput>
#REQUEST.Test.Message#
</cfoutput>
In a way, this ColdFusion custom tag works much like the front controllers in FuseBox or Model-Glue; all CFC creation is funnelled through this one template. Now, I am not sure you would want to use this all over the place. What you might want to do is create some sort of globally accessible user defined function that creates a kind of second layer proxy to this tag; otherwise, you would have to supply the custom tag template path every time you invoke a component.
Regardless, I thought this was a very cool idea that Jeff came up with.
Want to use code from this post? Check out the license.
Reader Comments
Actually, I think this has legs. I've often set a request.componentDir variable where I can swap out pathing based on environment.
Maybe in development:
request.componentDir = "../components.";
Then in production, maybe I have a mapping:
request.componentDir = "/componentMapping.";
The proxy solution, however, could potentially remove any need for mappings while at the same time removing the need for environment configs for component locations. I'll have to give it some more thought as well.
Thanks!
@Jason,
Sounds good. Let me know what you come up with.
Interesting idea....
Something else you could do is restructure a bit and do:
/root/
/root/cfc/
/root/cfc/createCFC.cfm
/root/cfc/com
/root/tags/
/roow/www/
You could then use CF 8's ability to create Application mappings for a custom tag path:
application.cfc:
this.customTagPaths = getDirectoryFromPath(getCurrentTemplatePath()) & "..\cfc\," & getDirectoryFromPath(getCurrentTemplatePath()) & "..\tags\;
Now you'd be able to call the <cf_createCFC /> directly within your application.
Heck, you could then even create a UDF that would call the CF Tag for you, so you'd just could do:
createCFC()
@Dan,
I like it. I gotta play around more with the application specific mappings in CF8. I have to be honest, I used to hate the idea of mappings because it was another "moving part" (ie. talking to server admin) that might break and could be a hassle with portability. However, since CF8 puts mappings into the hands of the developer, my whole outlook on mappings in general might be shifting.
@Ben:
First, I just blogged about your concept over at my blog and expanded a bit on my comment:
http://blog.pengoworks.com/index.cfm/2008/1/16/Invoke-CFCs-outside-of-webroot-without-mappings
I agree about issues with mapping--which is why one of the features I always request when Allaire/Macromedia/Adobe would ask is application-level mappings.
As I stated in my blog, the closer I can get my applications to just copy and run, the happier I am. It makes it much easier to migrate code to new servers and if you're trying to sell an application, I think you want to make things as easy as possible to configure.
That's why I was so happy when we finally got a this.mappings and this.customTagPaths variables.
Also, technically using CF8, you could just use the this.mappings to set up a mapping to the /root/cfc/ as well.
However, your technique works well for pre-CF8.
@Dan,
You post is quality stuff. Thanks.
This is good stuff.
I was going to suggest a UDF, but Dan is way ahead of me on that.