Not that I don�t agree with you on many points, but consider the other reasons that CFCs exist, which do not necessarily relate to OO. From the MM Docs:
Consider using ColdFusion components when doing the following: � Creating web services. (To create web services in ColdFusion, you must use components.) � Creating services that are callable by Flash clients. � Creating libraries of related functions, particularly if they must share data. � Using integrated application security mechanisms based on roles and the requestor location. � Developing code in an object-oriented manner, in which you use methods on objects and can create objects that extend the features of existing objects. Again, I just want to illustrate that CFCs have far more uses than just OO, and that OO is in fact a fairly advanced topic. That should not, however, discourage people who use CFCs for reasons other than OO from asking questions on this list. Also, it's a pretty safe bet that those of us on the list that use OO principles for development are also more than capable of developing in a procedural fashion. That also means that we're capable of answering a procedural question without preaching OO as the correct answer ;) Anyway, I'm not trying to argue against OO or CFCs or OO in CFCs (in fact, I encourage it). I'm just trying to make sure that we all remember that not everyone does things in an OO way and that procedural development is just as valid as OO (and in fact has been around longer). Cheers :) Roland ________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Rypka-Hauer - CMG, LLC Sent: Monday, April 04, 2005 10:03 PM To: [email protected] Subject: [CFCDev] CF, OO, and CFCs I kinda feel bad for Ken... Sorry your thread turned into a debate. As far as all the talk regarding OO and CFCs, I've got a couple things to say... Fist and foremost... if you want to use CFCs, USE THEM! They're fab. They're fun! They're like way excellent, man, and I highly recommend that you use them. I love talking about them, helping people understand how they work and what the best uses and best practices surrounding them are. As far as asking questions, I encourage that as well! Nothing accellerates the learning process like asking questions... no doubt. And like I said, I love answering them. It's fun. I'm from a family of teachers and teaching is in my blood, so I really groove on it. I'm having the time of my life, in fact, I may have found my calling... However, that's not where it stops. There are some ground rules regarding CFCs, and it's these ground rules that seem to be what people keep tripping over... so bear with me, if you will, as I opine on the subject of CFCs, OO, and why "preaching" isn't "preaching" at all... First of all, CFCs are what amount to CF executables. As such, their functionality, use, and best practices fall along a certain line, and, because the whole idea was derived from OO and runs on Java, those rules also fall along the OO line. In effect, this means that you need to, if _nothing_ else, be aware of some OO elementals or you're going to have some problems. So, if someone says "How do I write an OO shopping cart in ColdFusion?" the answer is going to be, at least in part the *same* as the answer to "How can I use a CFC as a UDF library?" Both are still going to have to be aware of dangers and blessings that go with CFCs. Both are going to need to be aware of the difference between a stateless CFC and a stateful CFC, and if they want to get more complex implementations working, they're going to have to learn some of the vocabulary so they can ask their questions using terminology understandable by those who know the answers. If you're going to work with CFCs, you need to know how the this, variables, and function-local scopes work. You're going to need to know how objects returning data work, you're going to need to know� how exceptions are handled, especially when you're using composite objects (nested CFC instances) and you're going to need to know that when you call createObject("component","user") you've created an object from a class, but when you call createObject("component","user").init("Fred Smith") you just instantiated the user object Fred. You really should understand the idea of "context" as it applies to the variables scope, and how any entity that has it's own variables scope has a getPageContext() method, what that does and how it works... because the idea of context underlies everything we do as developers. These things are important because they all affect they wan an application operates. Where do you lock a session-scoped CFC? Is it OK to have a UDF that has instance data? What's instance data? The people that know the answers speak this language... if you want to talk to people from Spain, you learn Spanish (or hire an interpreter!), and if you want to talk CFCs to those who know them, naturally you're going to have to learn to speak their language. It's not preaching, it's life. It's expecting a shock if you stick your finger in a light socket. Anyway, no matter how you use them... in a UDF-with-Properties or in a full OO implementation... CFCs are *by nature* an object-oriented topic. Consequently, "CFCDev" carries with it a level of object-oriented focus simply because it exists... All that said, keep this in mind as well: I AM running a site right now, that I started on just before MX 6.1 came out. It's entirely based on the use of CFCs as "UDFs-with-Properties" For every page request, an instance of a CFC is created that is used to generate the content for the page, and for every action page I'm setting this.varName and then calling object.update(), or add(), or delete(). Does it work? YES. It is a lovely, clean implementation that takes advantage of the technology like I'd LIKE it to? NO. Did I know any better at the time? No again. Do I think it's the best way to build an online application? Absolutely not. It's a heck of a dynamic website though. I'm very proud of it, and it was lots and lots of work. I'm actually dying to refactor the whole thing into a cleaner version. In the end, I think everyone will benefit if people understand the nature, care and feeding of CFCs and why they're so closely linked with both the CF OO community and OO vocabulary. It's the nature of the beast... and it's a time-and-experience-tested beast at that. Why not adopt it? Anyway, I don't know if that was helpful, infuriating, or just a complete waste of time... but I feel better. :) Laterz! J -- Continuum Media Group LLC Burnsville, MN 55337 http://www.web-relevant.com http://www.web-relevant.com/blogs/cfobjective ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
