No, to be honest Aaron I really didn't think that far ahead. But that seems like a nice solution. Of course the real solution is "don't put stateful things into utility classes" =)
Eric On 3/19/07, Aaron DC <[EMAIL PROTECTED]> wrote:
I think storing functions in a CFC in application scope would be handy, especially if there was a bug in one of them :) One quick change and everyone gets the fixed function, without having to refresh everyone's session scope (potentially clobbering their utility class state info in the process). If we're storing state info, I'd be tempted to store it separately to the functions and leave the functions in Application scope - is this the "flavour" decision you are talking about? Aaron Eric Knipp wrote: > Nando, > > The one point I was trying to make is that by putting it into request > scope, you eliminate the need to do a bunch of find-and-replace later > on if you decide that in fact the utility class retains some kind of > state and has to be in session scope (for example). This way you only > have to change your code in one place, which seems better. But really > that is kind of a "flavor" decision and could be more confusion than > its worth. > > Eric > > On 3/19/07, *Nando* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > It doesn't make any sense to me to copy a /reference/ into request > scope. > > CFC's are copied by reference, which means that here you're simply > assigning the variable another name in a different scope. I'd just > go ahead and work with it in application scope. > > As far as i'm aware, application scope works in custom tags. I > have one in production open in front of me, just to confirm my > memory is correct on this. > > HTH, > Nando > > On 3/19/07, *Eric Knipp* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Its my understanding that CFC's are copied by reference, so I > don't see how copying the CFC into the request scope helps you > at all, except that it does make it easier if you were to > switch to some other container (other than application scope) > at some point. > > > On 3/19/07, *J MacKay* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hopefully someone can answer two newbie questions .. > > I've read a few blog entries about storing general utility > components in the application scope so they can accessed > anywhere within the application. > > <cfif NOT isDefined("application.Utilities")> > <cflock scope="application" type="exclusive" timeout="10"> > <cfif NOT isDefined("application.Utilities ")> > <cfset application.Utilities = > createObject("component", "Utilities")> > </cfif> > </cflock> > </cfif> > > <cflock ...> > <cfset Request.Utilities = application.Utilities> > </cflock> > > It makes sense to instantiate the component once and store > it in the application scope, but 1) why copy it back into > the Request scope ? So it will be available to custom > tags? 2) Why is it necessary to use a lock when copying > the component into the request scope? > > ------------------------------------------------------------------------ > No need to miss a message. Get email on-the-go > < http://us.rd.yahoo.com/evt=43910/*http://mobile.yahoo.com/mail%0A> > with Yahoo! Mail for Mobile. Get started. > < http://us.rd.yahoo.com/evt=43910/*http://mobile.yahoo.com/mail%0A> > > You are subscribed to cfcdev. To unsubscribe, please > follow the instructions at > http://www.cfczone.org/listserv.cfm > <http://www.cfczone.org/listserv.cfm> > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com <http://www.katapultmedia.com> > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > <http://www.mail-archive.com/[email protected]> > > > > You are subscribed to cfcdev. To unsubscribe, please follow > the instructions at http://www.cfczone.org/listserv.cfm > <http://www.cfczone.org/listserv.cfm> > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com <http://www.katapultmedia.com> > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > <http://www.mail-archive.com/[email protected]> > > > > You are subscribed to cfcdev. To unsubscribe, please follow the > instructions at http://www.cfczone.org/listserv.cfm > <http://www.cfczone.org/listserv.cfm> > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com <http://www.katapultmedia.com> > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > <http://www.mail-archive.com/[email protected]> > > > > You are subscribed to cfcdev. To unsubscribe, please follow the > instructions at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
