A quick, unordered, outburst of ten tips for folks (new to) using CFCs. Feel free to add more, or tell me I'm a moron and that I forgot something.
1. Don't use the "this" scope.
Unless you know when and why something should be "public," err on the side of caution and avoid the "this" scope like the plague. Instead, write a function that returns the data you're after.
2. Don't talk to application, session, client, etc.
This reduces the reusability of your CFC: instead, pass it either the scope or the specific data it needs.
3. Use those "hint" attributes.
Your boss will be muy impressed by the slick-looking automagically generated documentation you can create via the CFC explorer, especially if you use CF7 to create a PDF out of it!
3. Understand ColdFusion mappings
It's easy to get confused when you don't understand mappings and ColdFusion is just sitting there telling you that "my.wonderful.earth.shattering" CFC can't be found.
The nickel tour on Windows + IIS + default CF/IIS install (glossing over Custom Tag caveats):
ColdFusion starts looking for CFCs by name at the ColdFusion root (by default, probably the same as your web root, e.g., "c:inetpubwwwroot"). If you try to load the "my.wonderful.earth.shattering" CFC, it'd look for c:inetpubwwwrootmywonderfulearthshattering.cfc. However, if you create a ColdFusion mapping of "/my" pointing to c:mystuff, it'd look for c:mystuffwonderfulearthshattering.cfc.
4. Don't get too caught up with OOP and Design Patterns
They're a lot easier to learn if you do stuff on your own and screw up. Otherwise, it's hard to "see" why they're good things.
5. Just do it
Going back to #4, CFCs in general are easier to learn if you screw up and then think about how you did things.
6. Create constructors and name them "Init."
Always create a in your CFCs named "Init" where the returntype is the name of the CFC (e.g., "my.wonderful.earth.shattering") and the last line is <cfreturn this />. It'll make you look like one of the cool kids, and you'll thank yourself later.
Example: It's a lot easier to pass the Init() method a datasource name and store it in the variables scope than it is to pass it to all of the cffunctions that need the datasource name.
7. Use the variables scope!
CFCs aren't just function libraries! They can hold data *in between* calls to their functions. If you have a CFC that mainly serves to query a database, you can "tell" it its datasource name, and it'll remember it when you call selectMyStuff() and updateMyStuff(), instead of having to pass it along each time.
8. Remember thread-safety.
Just because a CFC you're writing now isn't going to be placed someplace dangerous (like the application scope), it doesn't mean it never will. Luckily, thread safety in CFCs is usually as simple as declaring every variable, every time, with the "var" construct. Variable declarations always come after the list, and before any more code, or CF will throw an error. Example:
<cffunction name="doSomething">
<cfargument name="foo" />
<cfset var result = "" />
<cfreturn result />
</cffunction>
9. Don't let them output anything
Your CFCs should be used for logic purposes, not to print things to the browser. If you want to create HTML in them, create it and pass it back.
In other words, don't do this:
<cffunction name="sayHello">
<blink>Hello!</blink>
</cffunction>
Instead, do this:
<cffunction name="sayHello">
<cfreturn "<blink>Hello!</blink>" />
</cffunction>
This tip brought to you by the Campaign to Save the Marquee Tag
10. Keep them small!
If your CFC seems like it's doing a lot, and has functions that aren't really related to one another (say, addNewColdFusionDatasource() and orderAMushroomPizza()), it may be time to split it into two (DatasourceManager and PizzaOrderer).
10 comments - Posted by Joe Rinehart at 2:59 PM - Categories: ColdFusion MX