Welcome!

ColdFusion Authors: Mike Kavis, Yakov Fain, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: Article

component.cfc: The Mother of All Components

component.cfc: The Mother of All Components

Yes, that's right, components have mommies and daddies. Well, not really, but that statement isn't too far from the truth. This article explains "component.cfc", a hidden gem in the ColdFusion Component architecture that is part of ColdFusion MX.

By now, everybody knows that the introduction of the component framework in ColdFusion MX was one of the most radical changes to CFML since its inception. Their introduction was significant for three primary reasons. First, they allow developers to expose functionality to the Flash Gateway and to any other Web service-enabled environment. Second, they offer a level of abstraction far superior to that of custom tags and user-defined functions. The third reason CFCs have made such an impact on CFML is that they offer ColdFusion developers the ability to implement object-oriented features.

These object-oriented features include new variable scopes with varying degrees of exposure outside the component; the "packaging" of functionality, introspection, and the generation of meta data; objectinstance- based programming; and inheritance. In traditional object-oriented programming languages, all objects inherit from a parent "Object" class. What many developers don't realize is that components, too, have a parent "class". Its name is "component.cfc" and it can be a very valuable tool when developing applications.

Where Can I Find component.cfc?
If you create a CFC that does not inherit from any other CFC and you view its meta data, you'll notice that the value for the "hierarchy" meta information defaults to "WEB-INF.cftags.component". You will find this file in the "CfusionMXWWWRootWEBINFcftags" directory if you're running the standalone version of ColdFusion, and in "JRun4servers{your_server_name}cfusion-earcfusion-warWEBINF cftags" if you're running the J2EE version (on top of JRun4). You can view the meta data for component.cfc on a server by browsing http://{server_domain}/CFIDE/componentutils/cfcexplorer.cfc?method=getcf cinhtml&name=WEB-INF.cftags.component, replacing "{server_domain}" with "localhost:8500" or whatever other URL you use to browse to that machine.

What Does component.cfc Do?
Well, nothing really. Not out of the box, anyway. The component.cfc file is empty by default in ColdFusion MX 6.1. In ColdFusion MX it had a tiny bit of encrypted data at the top of the file. As already discussed, all components inherit from component. cfc by default. Think of it as the Application.cfm of components - a place to put code that is implicitly included. The difference is that the code outside of any method in component.cfc is executed only when a ColdFusion Component is first initialized, and that its methods and meta data are inherited by other components. It gives you a single place to put code that must be common to all CFCs on your server.

Why Would I Want to Do That?
Having one place to put functionality and initialization code that will be available to all server components has two important uses. As already mentioned, you can think of it as similar to Application.cfm, which means that if you're running a server that's dedicated to hosting one application and the application is using CFCs for its business logic (as every application should be), it's a very good place to put functionality that all components need to have.

For example, if your server is hosting your company's public Web site, all of your components might need to have access to the current company catalog of products. Creating a method in component.cfc that retrieves the current catalog information from a database and returns it to the caller would ensure that all components have the ability to retrieve the catalog by calling that method. While this is a neat trick, it's not always terribly useful or desirable, especially when your application is running on a server that hosts other completely separate ColdFusion applications.

There's another use for component.cfc though - when wielded properly, it can be a powerful development tool. More than anything else, I like to put debugging methods in my component.cfc file so that they are available in any application I happen to be working on. Extending the component framework with development tools can make a developer's life a little bit easier, as we will soon see.

Coding with component.cfc
It's a little known fact that ColdFusion Components don't technically require a start and end <cfcomponent> tag… they will work without them. That said, without the <cfcomponent> tag, a CFC will not properly inherit from the base component. cfc file nor will it allow the use of <cfproperty> tags if you are defining meta information, so as a best practice, follow the standard recommended practices when creating components.

By default, component.cfc is an empty file. Because it does not inherit from any other component (after all, it is the mother of all components), you can code methods in the file without adding any <cfcomponent> tags. You can optionally add <cfcomponent> tags to component.cfc in order to generate meta data about the component or to enable the use of <cfproperty> tags before your methods. Like inheritence with other CFCs, any meta information, methods, and variables in the component are inherited by all other components on the server.

As you may have guessed, creating a method in one component with the same name as a method in component.cfc will override the method. The original method defined in component.cfc can be accessed with the "super" keyword as "super.methodName()", provided that the component you are in does not inherit from any other component. Let's examine one very practical use for this master component file.

Component.cfc Uses
If you're anything like me, you use <cfscript> a lot. As wonderful as <cfscript> is, it is not without limitations. In particular, the use of tags is strictly forbidden within a <cfscript> block. It is often necessary during the development process to view data in order to determine what's happening in your code. The <cfdump> tag is perfect for this, but wait - you cannot <cfdump> within a <cfscript> block. What to do?

Developers like me who use <cfscript> often, have made it a standard practice to create a function using <cffunction> that accepts a single argument of any data type, <cfdump> that variable, then <cfabort> the page. That function can then be called from <cfscript>, thus giving developers the ability to "see what's happening" within their <cfscript> code.

Here's the code I wrote inside of my component.cfc file so that I can dump a value from any ColdFusion Component <cfscript> block:

<cfcomponent displayname="Root" hint="Root CFC">
<!---:: function to dump then abort ::--->
<cffunction name="dumpIt" output="true" displayname="Dump It" hint="A
debugging tool" access="private" returntype="void">
<cfargument name="it" displayname="It" hint="The Thing To Dump"
required="true" type="any">
<cfdump var="#arguments.it#">
<cfabort>
</cffunction>
</cfcomponent>

You'll notice that the method is private because I do not need nor want to expose it to cfm pages that are instantiating my components. It also means that the method does not display along with the other methods of a component that's inherited it when that component's meta data is browsed.

The "dumpIt()" method is useful for developers who do not use <cfscript> as well. It is generally considered a best practice to encapsulate business logic with components. This means passing a value to a component method, operating on that value, and returning a value to the caller page or application. With this in mind, it's a safe assumption that the components in your application(s) aren't directly outputting anything to the HTTP output stream.

Pretty much every component I create not only uses <cfscript> heavily, but never outputs anything. To make sure nothing is output, I always set my <cffunction> tag "output" attributes to "false". This is definitely a best practice in most scenarios, but not being able to output directly from a component method also means you cannot <cfdump> the value of variables within the component when you're debugging your application. Once again, the "dumpIt()" method is a very handy tool, as from within a "silent" component, you can pass the suspicious variable to this method (which has the "output" attribute set to "true") in order to see what's going on in your code.

Where Do We Go from Here?
Component.cfc is a very practical debugging tool for developers and can also be a powerful part of your applications as well. We have looked at just one way that it can be used as an effective development tool. You could create variations of the "dumpIt()" function so that you have one method to dump and abort and another to dump and allow processing to continue. It wouldn't be difficult to add methods to your component.cfc that allow you to do other useful things such as time blocks of code using the getTickCount() function, for example.

Be forewarned that there are two major drawbacks to placing code, especially application rather than debugging/development code, in component.cfc. One is that from an architectural point of view, you are physically separating your code from the rest of your application business logic. The other is that you are making your code less portable - it's no longer a simple matter of copying a directory structure from one server to another in order to move your application when some of the logic is housed in component. cfc. Other than that, have fun and take advantage of it! The sky's the limit.

More Stories By Simon Horwith

Simon Horwith is the CIO at AboutWeb, LLC, a Washington, DC based company specializing in staff augmentation, consulting, and training. Simon is a Macromedia Certified Master Instructor and is a member of Team Macromedia. He has been using ColdFusion since version 1.5 and specializes in ColdFusion application architecture, including architecting applications that integrate with Java, Flash, Flex, and a myriad of other technologies. In addition to presenting at CFUGs and conferences around the world, he has also been a contributing author of several books and technical papers.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.