|By Ray Camden||
|August 23, 2002 12:00 AM EDT||
Because ColdFusion components are such a new feature, developers may not yet have a good idea of what constitutes best practices.
This article attempts to rectify that situation by enumerating a set of guidelines that should be used when designing and working with CFCs, one of the most interesting new features of ColdFusion MX. Bear in mind that because they're so new, even experienced developers are debating what makes sense as a "best practice." These types of articles are always a matter of contention. I encourage you to contact me or discuss the article on any of the public lists, such as this magazine's CFDJ-List. The best way we as developers can improve our own code is by discussing our methods with others. With that in mind, let's begin...
Normally a CFC is composed of a large set of methods. Let's discuss a few things to remember when building methods.
By default, all CFC methods have an access="public" setting. A method can have four different types of access. Public means that the method can be called from the local server or from instances of the CFC. The other settings are private, package, and remote. Private methods can be called only from other methods in the CFC itself. Package methods are those that can be called from other CFCs in the same package. Remote, the most open setting, can be called from any source, including remote servers and Flash files.
It's important that you remember the default setting of "public." While it's not as open as "remote," it may not be what you intend when designing your CFC. A simple way to handle this is to set all methods in the CFC to "private." This means your methods will be as secure as possible. "Open" up your methods only on a case by case basis. If you want to be truly anal (and when it comes to security, you can't be too anal), follow this practice even when you're "really, really" sure the method will be used publicly. Wait until you actually code the CFM that will call the CFC's method. At that point you can change the method being called.
The CFFUNCTION tag takes multiple attributes, many of which are optional. It's best to explicitly set most, or all, of them. At its basic level, CFFUNCTION needs a "name" attribute. However, each of the following attributes should be passed:
Let's take a look at a method with the barest essentials set:
<cffunction name="cartTotal">Now compare this to a method with most of the optional attributes set. It's much clearer what the method is doing and how it will return information.
... method code ...
<cffunction name="cartTotal"" output="false" access="private"
hint="This method calculates the total
price of all the items in the shopping cart.
It simply loops over the cart and multiplies
item price by quantity.">
We can also apply this same principle to the CFARGUMENT tag. CFARGUMENT, like CFFUNCTION, requires only the "name" attribute. However, you can - and should - pass the following optional arguments:
Once again, let's take a look at a method that doesn't use these optional attributes:
<cffunction name="cartTotal">Now consider the version in Listing 1. As you can see, the second version of the method is much clearer about what exactly it does.
... method code ...
Output vs Return
When calling a method on a CFC, you can display the output in multiple ways. The method itself can CFOUTPUT data or it can return the data to the caller. You should never CFOUTPUT. Instead, data should be returned by using the CFRETURN tag. There are a number of reasons for this. If you ever encounter a case where you don't want the result of the method displayed immediately (maybe you want to store the result in a database), you'll have to reengineer your method and any calls to it (unless you use CFSAVECONTENT to suppress the output).
Another reason not to use CF OUTPUT is because of a bug with persistent components. If you store an instance of a component in a persistent scope (like the Session scope), and if you call a method that outputs instead of returns data, you'll only be able to call it once. Any subsequent call will not display the output.
The most important reason not to output directly from the CFC is Flash. Any data that isn't returned from the method will not be usable from Flash applications that use your CFC. By using CFRETURN, you guarantee that it will work with both your CFML files and your Flash files.
Use the Var Scope
If you've read anything about user-defined functions, you've probably seen mention of the "Var" scope. This is a scope created specifically for the lifetime of the function. By creating data in this scope, you help ensure that a UDF doesn't accidentally overwrite variables in the template. The Var scope is just as important when working with CFC methods. Consider the following CFC method:
<cffunction name="returnFoo" output="false"This function simply sets x to 1 and y to the value of another method in the CFC, and then returns the value of x. You'd expect this method to return 1. However, guess what happens if returnGoo looks like the following:
hint="Returns the value of Foo">
<cfset x = 1>
<cfset y = returnGoo(x)>
<cffunction name="returnGoo" output="false"You might expect this to have no impact on our original function, returnFoo, but because the x value was never Var scoped, instead of getting 1 back, we get 100. To correct this we can simply add the Var qualifier to the sets in each method:
hint="Returns the value of Goo">
<cfset x = 100>
<cffunction name="returnFoo" output="false"Once this is done, calling return-Foo returns the value we expect, 1.
hint="Returns the value of Foo">
<cfset var x = 1>
<cfset var y = returnGoo(x)>
<cffunction name="returnGoo" output="false"
hint="Returns the value of Goo">
<cfset var x = 100>
Don't forget that any and all Var statements must be made before any real code. They should be placed immediately after any CFARGUMENT tag.
Another aspect of CFCs is the use of component data. This is data that persists for the lifetime of the CFC and is accessible to both the methods of the CFC and, potentially, the template using the CFC.
The This Scope
Two scopes can be used with CFCs. The first one, which will be used most of the time, is the This scope. Values can be defined in this scope just as in any other:
<cfset this.name = "Raymond">
Any variable defined in this scope is available to the calling template. For example:
<cfset theOb = createObject("component","test")>Conversely, if you pass a value to a CFC, it will automatically be placed in the This scope. Consider:
<cfset theOb = createObject("component","test")>Once the CFSET command is run, any method will have access to foo in the This scope.
<cfset theOb.foo = 1>
What are some things to consider when storing information in a CFC? Any information placed in the This scope is public. It can be read by the calling template and even changed. This is fine if you don't mind the information being manipulated. However, you may not always want that. If you have information that you want to persist in the CFC without possibly exposing it, simply leave off the This scope. Imagine the following code in a CFC:
<cfset this.name = "Raymond">This code creates two variables in the CFC. The first is a public variable called name. The second variable, id, is not public. There isn't a real name for this scope. I refer to it as a private scope. It's not the same as the Variables scope and you can't CFDUMP it, but it's a useful way to store data and keep it separate from the public variables.
<cfset id = createUUID()>
The CFPROPERTY tag, technically, serves little purpose for CFCs. Its main use is to help define return values for Web services. However, it can serve a useful purpose for CFCs as well. The first thing to remember is that the CFPROPERTY tag will not actually do anything at runtime. Consider the following line of code:
<cfproperty name="numberOfLegs" type="numeric" required="true">
While it looks like it may add a level of validation to the tag, it really just defines metadata for the CFC. In other words, it helps describe it. The only required attribute is name. Everything else simply helps describe the property. This can be useful in multiple ways. First of all, it shows up in the descriptor. Second, every attribute passed in is available via the getMetaData function. This means you could write your own validation routines. Consider the following CFPROPERTY tag:
<cfproperty name="numberOfLegs" type="numeric" required="true" range="1,8">
The range attribute isn't a real attribute, but it will show up in the metadata. It would be trivial then to write a method that validates the value for this.numberOfLegs to ensure that it falls between 1 and 8. As you can imagine, this is pretty open ended. Any attribute to CFPROPERTY can be passed and used. How it's implemented is completely up to the developer.
That's Not All, Folks...
As I said at the beginning, CFCs are a new feature. What makes sense to me, and others, at this point will seem a bit silly next year (or even a few months from now). If you have any ideas you'd like to add, or perhaps you see something you disagree with, please e-mail me. You should also visit www.CFCZone.org. This is a site run by Rob Brooks-Bilson. (It's in the same vein as www.CFLib.org.) The site will soon host free, and open source, CFCs that you can use in your own projects.
- Where Are RIA Technologies Headed in 2008?
- The Next Programming Models, RIAs and Composite Applications
- AJAX World RIA Conference & Expo Kicks Off in New York City
- Constructing an Application with Flash Forms from the Ground Up
- Building a Zip Code Proximity Search with ColdFusion
- Personal Branding Checklist
- CFEclipse: The Developer's IDE, Eclipse For ColdFusion
- Has the Technology Bounceback Begun?
- Cloud People: A Who's Who of Cloud Computing
- i-Technology Viewpoint: We Need Not More Frameworks, But Better Programmers
- Adobe Flex 2: Advanced DataGrid
- Web Services Using ColdFusion and Apache CXF