On the CFUN-04 Beat: Raymond Camden

Michael Smith:

Ray, I am intrigued about your "CFC Best Practices, Tips, and Tricks" talk at CFUN-04. Why should a programmer be interested in CFCs?

 

Ray Camden:

ColdFusion has always provided methods to help encapsulate code. However, CFCs (ColdFusion Components) are an extremely powerful new way of doing so. Being so powerful - they are a bit complex - and therefore not always as easy to use. I want my session to focus on things that the docs do not cover extremely well. I also want to show some interesting examples of CFCs in action. Basically, I assume you know the syntax but need help starting to use CFCs in real projects.

 

MS:

I always like to learn about things not covered by documentation! When you mention encapsulating code what exactly do you mean? And what are others ways than CFCs to do that?

 

RC:

In general, encapsulating code simply means taking common functions (or rules, business logic, etc.,) and moving them into one file. So at a simple level, if your business charges 10% more for people who are right-handed, you might create a custom tag that generates a price by checking to see if the buyer is right-handed. Since this logic is encapsulated in one file, multiple parts of your application can use it. If you ever decide to change the "Right-Handers Punishment" to 5% instead of 10%, you only need to change one file.

So obviously, custom tags are one way you can do this. UDFs are another. You can also use CFINCLUDE for simpler forms of encapsulation.

 

MS:

That is neat that changes happen in one file instead of hundreds of places in your code. Are there any other reasons that programmers should encapsulate their code?

 

RC:

Sure. If I have any complex set of logic, even if I know it will only be used on one page, I'll consider encapsulating it just to make the page itself a bit simpler. Especially if a page has a mix of display and business logic. If I can strip out the business logic to another file, then it becomes easier to debug (on both sides - design and logic).

 

MS:

What are the basics of writing CFCs that you will assume that people already know?

 

RC:

Just the basic syntax. If you can write a CFC and can describe the syntax of CFCOMPONENT and CFFUNCTION, then you should be ok. I'm aiming this session at the midlevel CF developer, who is just past the beginner stage.

 

MS:

Are CFCs any harder to write than modules or UDFs?

 

RC:

I'd say so - but not overly so. CFCs are more complex. They take more thought. I want to make sure I don't scare people. They are harder to write, but only, let's say, one "level" of complexity higher. I'm not sure if that makes sense.

 

MS:

Yes, that makes sense. Perhaps harder as in how a car is harder to learn how to drive than a bicycle?

 

RC:

That is a good analogy. There is nothing "wrong" with how cars are designed, but the process of using a car takes more thought than the process of riding a bike.

 

MS:

I have heard that CFCs use Inheritance - does that mean some code has to die? Or is that a Jedimaster thing?

 

RC:

What inheritance means is that we can create a CFC that is an extension of another CFC. Imagine an dog represented as a CFC. A dog has certain features -- four legs, a tail, bad breath, etc. A poodle is a kind of dog. It has all the features of a dog but has characterstics specific to a poodle (small, curly hair, etc.)

So, using a real world example: You may have a CFC that represents a core Product. This CFC will have methods for getting the price, description, shipping weight, etc. You can extend that Product CFC with a CFC called Book. This book has all the same properties and methods, along with things specific to books, like ISBN numbers.

 

MS:

So inheritance saves having to recode the same methods for similar CFCs?

 

RC:

Yes, you could say that. Although you want to make sure that you don't use inheritance where it doesn't make sense. Inheritance should be used where there is a "Is-A" relationship. I.E., a poodle is a dog. An Abstract is a type of Publication. If, however, you just want to use another CFC in your CFC and there isn't such a relationship, you should consider just creating an instance of that CFC.

An example: I typically create a CFC for my sites that holds all of my application settings. My other CFCs use this CFC. They don't extend it because obviously there aren't a type of "Setting", they are their own unique CFC, but they each create an instance of the CFC so they can grab settings.

 

MS:

That sounds like a neat way to code. I am looking forward to hearing more tips at CFUN. Thanks for talking with me.

 

Raymond Camden is a senior software engineer for Mindseye, Inc. A long time ColdFusion user, Raymond is a co-author of the "Mastering ColdFusion" series published by Sybex Inc, as well as the lead author for the ColdFusion MX Developer's Handbook. He also presents at numerous conferences and contributes to online webzines. He is a contributor and technical editor of the ColdFusion Developer's Journal. He and Rob Brooks-Bilson created and run the Common Function Library Project (http://www.cflib.org), an open source repository of ColdFusion UDFs. Raymond has helped form three ColdFusion User Groups and is the manager of the Acadiana MMUG. You can reach him at ray@camdenfamily.com.

• Subscribe
• RSS

• Editorial
• Specials
• Community
• News
• Tech and Tags
• Views
• Reviews
• Techniques
• Security
• Best of ColdFusion Talk
• Knowledge Base
• Blog Watch

• Tipical Charlie