Well said. Here here.
Mark
>
> 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
--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
ICQ: 3094740
----------------------------------------------------------
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]
