You dare speak out about thy FUSEBOX..did you not get the Johnny fork
analogy..ok, we are going to have to strip your brain down to bare
roots and rebuild, circuit by circuit.
Yuh, it has been layed on thickly (I too have contributed i
guess)...but it took some (as spike knows) sobering up, to sit back
and go "ya know this OO crap, is long winded at times...115 lines of
code to output "hello world"...it just seems tedious)
ie DG/DAO is getting to the points of religion now, I know a couple of
devs who are blindly using them because of this list.... yet they
don't realise it....hrm...... that can't be good.. i too suckled on
the teet that which is pure OO patterns and it took an intervention
from Spike to show me the way of a new religion.
I guess there needs to be a better balance reached. but now the
question is "how?" where do we go from here? whats the next
move...should we inherit or instantiate hehe.
Scott
On Apr 5, 2005 1:56 PM, Spike <[EMAIL PROTECTED]> wrote:
> As much as I like OO and as much as I think it's a good thing, I've been
> around the houses enough times to know that pushing one mode of thinking
> doesn't tend to foster too much innovation.
>
> CFCs are very capable of being much more flexible than just OO in their
> implementation and as long as people continue to cajole those who ask
> questions into thinking in an OO way, innovation is going to suffer.
>
> I vote for a scaling back of the "OO is the only way" attitude that this
> list seems to have adopted recently. It often doesn't provide the
> answers that people have asked for and it probably kills alternative
> possibly better suggestions.
>
> It reminds me very much of the religious fervor that usually surrounds
> fusebox. Again, I think fusebox is great, but I want to constantly
> explore new and innovative ways of thinking. As long as there is this
> overbearing insistence on OO thinking I don't think that is going to happen.
>
> my 2 c
>
> Spike
>
> Jared Rypka-Hauer - CMG, LLC wrote:
> > 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]
>
> --
> --
> --------------------------------------------
> Stephen Milligan
> Code poet for hire
> http://www.spike.org.uk
>
> Do you cfeclipse? http://cfeclipse.tigris.org
>
> ----------------------------------------------------------
> 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]
>
>
--
Regards,
Scott Barnes
http://www.mossyblog.com
http://www.flexcoder.com (Coming Soon)
----------------------------------------------------------
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]
