Although I agree in theory with a lot of what you said, I think in
practice the idea is more muddy.

Yes, most (well, many) web sites have a short lifespan: however PARTS of
those sites are very long lived.  So while
"myStupidIdeaToSellSandwichesOnline.com" may fold after a few weeks
parts of that site (if built well) should live on.

User registration, shopping cart, inventory management, activity
tracking, security, content management, etc (again, if built well) are
all reusable indefinitely and may, as individual systems, have lifespans
many times longer than any of the sites that use them.

It's exactly these kind of things that I think lend themselves perfectly
to CFC development.  I find that, most often, I'm designing a CFC model
to handle the definition and persistence of these systems, but not the
usage or administration.

For example I've designed a user-information/session tracking system.
The core files are all CFCs: user.cfc, session.cfc, clickstream.cfc,
etc.  The CFCs define the data, how it's stored, how it relates to other
data and so forth.

But there are two procedural systems then that use that model: an
administration system (for viewing metrics, editing user information and
such) and the actual website implementation.

These procedural systems are nothing more than "glue" (I know, clich�)
holding the conceptual CFC to the ground.  I can use that model with any
number of sites with custom implementations, admin systems, etc - but
the core model is safe and predictable.

I'm not saying that's the only way to use CFCs - a lot of folks have
switched to them for every aspect of a site, but with my procedural
background it's the way that makes most sense to me.

Jim Davis


> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of [EMAIL PROTECTED]
> Sent: Friday, November 14, 2003 11:40 AM
> To: [EMAIL PROTECTED]
> Subject: RE:CFC and actual use? (was [CFCDev] two CFC bad practices...
)
> 
> hmm...interesting.  The more I hear on this discussion the more I
wonder
> just how much CFCs are even needed in day to day apps.  How many apps
are
> really complex enough to use them?  But then I wonder, to me CFML is a
> "4g" styled procedural lang encapsulating "3g" styled langs, is this
> abstraction really needed in CF?  Throw in the fact that a web app
> typically has a short life span and I wonder even more.
> 
> ...some random thoughts on this topic.
> 
> Doug
> 
> >-----Original Message-----
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >Behalf Of Matt Liotta
> >Sent: Thursday, November 13, 2003 1:35 PM
> >To: [EMAIL PROTECTED]
> >Subject: [CFCDev] two CFC bad practices...
> >
> >
> >In case you didn't see it, I blogged a couple of CFC bad practices.
> >
> >http://devilm.com/archives/000066.html
> >
> >Matt Liotta
> >President & CEO
> >Montara Software, Inc.
> >http://www.MontaraSoftware.com
> >(888) 408-0900 x901
> >
> >----------------------------------------------------------
> >You are subscribed to cfcdev. To unsubscribe, send an email
> >to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
> >in the message of the email.
> >
> >CFCDev is run by CFCZone (www.cfczone.org) and supported
> >by Mindtool, Corporation (www.mindtool.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 word 'unsubscribe cfcdev'
> in the message of the email.
> 
> CFCDev is run by CFCZone (www.cfczone.org) and supported
> by Mindtool, Corporation (www.mindtool.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 word 'unsubscribe cfcdev'
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]

Reply via email to