Several people, Sean Corfield and Joe Rinehart most notably, have been blogging and emailing lists talking about the pros and cons of using cfincludes in CFCs. Sean is opposed to it, as am I, but Joe's got some mixed feelings. In a rush I simply commented on Sean's blog that this is bad form and defeats the purpose of Components. Joe'd like me to elaborate, so I will.

I should begin by stating something that many of you may be surprised to hear - I don't use ... EVER! The methodology I use, which I promise you'll all be able to read very soon, encourages breaking everything down to parameterized encapsulated modules. Code within a is neither encapsulated nor parameterized. It's unprotected and not as robust, either. I use Custom Tags for all UI elements and CFC methods for all business logic. Presentation tier logic also goes in my tags.

When ColdFusion Components were introduced to CFML several years ago (with the release of CF MX 6), they brought a whole new level of encapsulation to the language that is far more robust than anything we had before. I won't go on and on about the benefits of CFCs - let's just say, to keep things simple, that they introduced all the benefits of Object Oriented languages to CFML. There are some basic rules of OOP that I firmly believe in and apply to CFC use. One is that all business logic belongs in CFC methods. Another is that CFCs don't ever display anything - their methods are data in and data out. Given those two facts, what good can come from using an include within a CFC method? If the thing being included contains business logic then that code should be in a method. If anything, this is more reusable than having it in an include file. If the thing being included generates output, it's OK for that code to talk to CFCs but should never be used by a CFC (since they shouldn't be writing to the screen).

Whether or not you agree with the notion that CFCs should never write to the screen or with the idea of never using at all in your applications, is irrelevant. CFCs are encapsulated and parameterized - all of the data and functionality that a CFC needs should either be contained inside that CFC or inside of another CFC(s).

I'm still waiting for someone to give me an example where using inside of a CFC makes more sense than having all of your logic in components. The talk between Joe and Sean began when Joe started looking at Mixins in CF (Go read his post at http://clearsoftware.net/index.cfm?mode=entry&entry=BC62A7BA-E081-2BAC-690DA2E20D609568 for more on that). Mixins appears to me like a convoluted way to implement the Aspect Oriented Programming technique of 'weaving'. Weaving aspects is an interesting idea, but I wouldn't choose to use in order to implement it. How would I implement it? I think I'll save that for another day, since this entry is pretty long already, but if anyone out tere would like to see me implement AOP in CFML, I don't mind doing it.