> Is there a best practice for using CFCs and CF? Yes, there are best practices for using CFCs, and most of them are largely drawn from best practices in any other class-based OO programming language, such as Java. Your best bet for understanding these best practices is to learn general OO programming concepts, which can then be applied pretty easily to CF in many cases.
> I read the documentation on CFCs and there are lots of ways > to use them. > > You can use CFinvoke, CFScript you can make a mapping to your > CFCs or you can keep them local to the CFM pages. You can > use CFInvokeArgurments or just place arguments in CFInvoke. There's nothing wrong with any of these approaches, actually. There are places where it may make more sense to use one than another, but the differences are pretty minor. In general, it's pretty common to use CFINVOKE when using a CFC as a static class, and to use CFSET or CFSCRIPT along with CreateObject when using a CFC as a class template from which you want to create instances. But the differences between one and the other are more a matter of personal preference than "best practice". > Inheritance and persistence confuses me some.. when should > you use them? Persistence doesn't really have anything to do with CFCs. You persist CFC instances just like you'd persist any other variable in CF. If, for example, it makes sense to store something in the user's session, it doesn't matter whether it's an object instance or an array or structure or whatever. Inheritance (and composition, and a bunch of other things) are part of OO, and you should use them when it makes sense to use them. That's pretty much a non-answer, but an actual answer would require a lot more explanation, and you're going to have to learn OO programming anyway. But, for a quick example, let's say you have people in general that you want to represent in your program, and they all share common characteristics. So, you might write a Person CFC that you will use to create Person objects. You might also have different types of people, who have their own characteristics in addition to those common characteristics, say Customers and Employees. It would make sense in this case to have Customer and Employee CFCs that extend Person, to add those type-specific characteristics. That's inheritance. A customer "is a" person; inheritance is an "is a" relationship. The other common relationship, composition, is a "has a" relationship. For example, people might have addresses, or roles, or whatever, that might be represented by their own CFCs. > I found the book 'Discovering CFCs: ColdFusion MX Components' > but it got rough reviews on amazon.com. I think it's actually a pretty good book, it was just written at a very bad time. When CFMX first came out, CFCs had lots of problems and limitations, and this book spends a significant amount of time covering workarounds for those limitations. Since then, newer versions of CF have removed many of those limitations, making the workarounds unnecessary. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! This email has been processed by SmoothZap - www.smoothwall.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Upgrade to Adobe ColdFusion MX7 Experience Flex 2 & MX7 integration & create powerful cross-platform RIAs http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJQ Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:272950 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
