Yes, points one and two are correct. Regarding your reservations, I'm afraid I don't share them. I don't see a problem with 'hardcoding' the locations of the objects in the application scope, this is simply a part of configuring the application, just like every application requires its specific settings. I'm not sure what you're suggesting is being 'lost' by hardcoding an application scoped setup like this; maintainability? flexibility? The app contains the ability to reset the application scope and reinitialize via a url param, so adding or removing a given app scope object is nothing more than modifiying the application object definition file (a separate include that is included within an application level lock) and restarting the app. One would suspect that constant modifying of these definitions wouldn't occur on a production deployed application, so I don't see it as an issue.
Which leads to your last comment about reinitialization during development. Its valid, but I think you're overestimating the reinitialization burden. Instead of the 16ms to 130ms per page execution time once the framework is initialized, you're talking about 1200ms or so should you pass the app reinitialization url param to force the reloading of the app. That occurs once in a while and don't find it a big deal. With regards to your second comment and the singletons persisting for the life of the application, yes to that; but again I fail to see the problem here. Pre-instantiate an object and simply 'tear off a copy' when you need it, or fully instantiate the object when you need it? I have to think the memory footprint of the first one is really minimal, and certainly better performing overall than the second. We're talking about a single instance of an object here. Lets say you had 100 individual singletons doing nothing and sitting around in the app scope waiting to be 'copied' and used, but at any given moment you used what, three? I don't see the issue there. What is your concern, memory consumption? -Kevin > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Matt Liotta > Sent: Monday, September 06, 2004 7:50 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] singleton pattern > > > Just to make sure I understand your solution, let me restate it. > > 1. You have a CFM that loads any CFCs you want a single > instance of into hardcoded application scoped locations. 2. > All uses of those CFC instances are done by referencing that > hard coded path. > > The above certainly works, but I have two issues with it. > First, I don't like hardcoded locations. Second and more > importantly, the solution only works with singletons that > persist for the entire life of the application. It does not > work for singletons that are only shared as part of a > request. Lastly, it seems this approach wouldn't be very > convenient during development as all the singletons would > need to be reloaded on every request since they may have > changed as opposed to only reloading what is needed for a > particular request. > > -Matt > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Kevin J. Miller > > Sent: Monday, September 06, 2004 2:03 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] singleton pattern > > > > During the application initialization phase (essentially > just a check > > for the var application.initialized), a series of structs > is created > > within the application scope declaring factories. All > components that > > are sensitive to > > factories simply always look there. > > > > application.serviceFactory = structnew(); > > application.serviceFactory.bandwidthService = > > > createobject("component","#application.paths.rootModelPath#bandwidthSe > > rvic > > e" > > ); > > application.serviceFactory.bookmarkService = > > > createobject("component","#application.paths.rootModelPath#boo > kmarkService > > ") > > ; > > > > application.presentationFactory = structnew(); > > application.presentationFactory.shell = > > > createobject("component","#application.paths.rootPresenterPath#shellPr > > esen > > te > > r"); > > application.presentationFactory.exception = > > > createObject('component','#application.paths.rootPresenterPath #errorPresen > > te > > r'); > > > > Etc. > > > > There is no ambiguity since the factories are only in the > application > > scope. As far as a cfc's existence, app.cfm contains a check for > > isdefined("application.initialized") and if that fails it > reads in the > > factory definitions (my snippet above) and keeps going. > There are also > > validation checks in certain instances when invoking some of these > > factories, but for all intents and purposes if you got to a > page or cfc in > > the app, the app scope already contains the objects. I'm > reworking a > > medium > > sized app and have only tested on my dev server with > myself, but so far > > the > > various components and the application.factory methodology > has passed unit > > testing nicely. > > > > -Kevin > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Matt Liotta > > Sent: Monday, September 06, 2004 6:57 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] singleton pattern > > > > > > > This component that gets scoped to the application scope (it's a > > > service component). It has some constructors, namely > other cfc's it > > > uses internally (common functions, error related functions). > > > > > The problem I am discussing is more related to managing of > CFCs in the > > application scope. You state that your component is in the > application > > scope, but how does it get there? Where do you create it? How do > > "users" of said component know where in the application > scope it is, > > whether it exists, > > etc? > > > > -Matt > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email to > > [EMAIL PROTECTED] with the words '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 words '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 words '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 words '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]
