True. I've added it. Being anal about the rules is important when doing tight code. Skimp on a rule and you can be screwed somewhere down the line. As this is a new personal methodology, it has to be 1000% solid.
> Just to be anal, I'd say it's not a good practice to define structures > like that. I'd at least do: > > <cfparam name="application.cfc" default="#structNew()#"> > > MX fixed the issue with auto-creation of structs, but I still think it's > better to be explicit. > > ======================================================================== > === > Raymond Camden, ColdFusion Jedi Master for Mindseye, Inc > (www.mindseye.com) > Member of Team Macromedia (http://www.macromedia.com/go/teammacromedia) > > Email : [EMAIL PROTECTED] > Blog : www.camdenfamily.com/morpheus/blog > Yahoo IM : morpheus > > "My ally is the Force, and a powerful ally it is." - Yoda > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Dinowitz > > Sent: Friday, July 25, 2003 11:38 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [CFCDev] CFC Caching > > > > > > I see what your doing below and its basically what I'm doing: > > <CFIF Not IsDefined('Application.CFC.User')> > > <CFOBJECT NAME="Application.CFC.User" > > COMPONENT="lotauctions.components.user"> > > <CFINVOKE component ="#Application.CFC.User#" method = "Init"> > > <CFINVOKEARGUMENT NAME="dsn" VALUE="#DSN#"> > > </CFINVOKE> > > </CFIF> > > Same thing except you have more 'control code' in it. As for > > putting things of this sort into sessions, I really fail to > > see why. Why put the entire CFC into each persons session > > when you can just assign them some session data (username, > > etc.) and then call some application CFCs to process it. > > > > > > > I've done this and have no complaints thus far. The CFC's I cached > > > were all data layer components as well. The only tip I that seems > > > important enough to share is that you should code in a way > > that lets > > > you ignore the cache or even rebuild it so things are more > > convenient > > > during development. I did a > > > this: > > > > > > <cfset bUseappcache= 1> > > > <cfif not isdefined("APPLICATION.CFC")> > > > <cfset APPLICATION.CFC=StructNew()> > > > </cfif> > > > <cfif (NOT bUseappcache) OR (StructIsEmpty(APPLICATION.CFC)) OR > > > (isDefined("URL.killCFC"))> > > > <!--- Put the components into memory ---> > > > <cfobject component="Components.ResourceLocator.category" > > > name="APPLICATION.cfc.category"> > > > <cfobject component="Components.ResourceLocator.feedback" > > > name="APPLICATION.cfc.feedback"> > > > ..... <!--- lot's more components ---> > > > </cfif> > > > > > > > > > During development bUseappcacheis 0 so that changes made to the > > > components show up immediately. In production bUseappcache is 1. > > > > > > Craig Fisher > > > InterWEST Technology Group, Inc > > > http://www.itg-ak.com/ > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > Behalf Of Michael Dinowitz > > > > Sent: Friday, July 25, 2003 8:51 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: [CFCDev] CFC Caching > > > > > > > > > > > > I'm playing around with a new methodology and part of it involves > > > > caching some CFCs into the application scope. I see no > > problem doing > > > > so but others may know > > > > more than I in this. Is there a savings in doing this? Any > > > > overhead or problems > > > > that I don't foresee? > > > > > > > > The first thing I do is check if its in the application > > scope and if > > > > not, create and initialize it. Then I just use it when needed. > > > > There's no locking going on > > > > as the CFC is only doing queries and related operations (no > > > > insert or update > > > > operations). > > > > > > > > Michael Dinowitz > > > > Finding technical solutions to the problems you didn't > > know you had > > > > yet > > > > > > > > ---------------------------------------------------------- > > > > 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). > > > > > > ---------------------------------------------------------- > > > 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). > > > > > > > ---------------------------------------------------------- > > 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). > > > > ---------------------------------------------------------- > 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). > ---------------------------------------------------------- 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).
