I’ve been putting this off for a while. I’m not sure why, maybe it was just laziness. Anyway, I feel it’s time to buckle down and finally learn to create and use CFCs correctly… You know, to unleash the power, so to speak.
Ok, I know now you are thinking I’m talking about chlorofluorocarbons (CFCs) but I’m not. What I actually am trying to get a firm grasp on are ColdFusion Components (CFCs). What are these, you ask?
From the Coldfusion Live Docs
A ColdFusion component (CFC) is a file saved with the extension .cfc. A CFC can contain data and functions. Within a CFC, data is referred to as properties. Although you use the cffunction tag to define functions within a CFC, they are typically referred to as methods instead of functions.
The page on which you define a CFC is also known as a component page. Component pages use the same tags and functions that regular CFML pages do, plus a small number of special tags (in particular, the cfcomponent tag) and tag attributes.
You define related methods in a CFC. Unlike ColdFusion custom tags, a single CFC can perform many related actions, defined in multiple methods. The methods may share a data context, such as metadata and scoping, or manage a particular database or set of tables. For example, you can define the methods to insert, update, delete, and retrieve records from a particular database or table in one CFC.
So there ya go. Sounds fun and useful, right? Well, thus continues my quest at bettering my Coldfusion knowledge and hopefully taking one more step forward in my Coldfusion Jedi Training. Because we all aspire to be like the master. Tomorrow, I hope to have, for your approval of course, my first CFC.
© 2008 – 2009, Robert Owen. All rights reserved.
As you work with CFCs you’ll discover asynchronous gateways and that’s where ColdFusion really become fun! I like being able to hand something to a server and say, “get back to me with that.”
I had a scrapper project once where the wholesaler would provide updated pricing and limited product information to a resellers via xml which was downloadable from a passworded administrative area but the xml file failed to contain product descriptions leaving the resellers the arduous chore of manually creating descriptions for new products and the impossible chore of recognizing which existing products had updated descriptions.
The XML part was easy. A scheduled task ran nightly that used CFHTTP to log in and grab the XML file, it was processed updating prices, removing out-of-stock or retired products, and logged its results with CFLOG.
The descriptions was more difficult. The database only had a couple thousand products but that was enough to timeout the connection when trying to loop over all the products and use CFHTTP to scrap the description from the manufacturer’s website. The solution was to have a scheduled task run weekly that launched a .cfm template. That template would read a certain number of products from the reseller database (which had been updated in the XML process) which I think was 500. Then with those ids it would call a CFC which was set up as an asynchronous gateway. The CFC would loop through that smaller number of ids and use CFHTTP to get product descriptions avoiding timeout issues and of course log its results with CFLOG. Since it is an asynchronous gateway, several batches of ids could be fetched at once, that is, ids 1-500 could be scrapped simultaneously with ids 501-1000 and 1001-1500…
That was actually one of my favorite projects.
Wow! I didn’t realize that post was from Sept 08.
Yeah… I haven’t posted my update to that yet… “Things” keep getting in the way. Thanks for the info though!! 🙂