Having read some of the other responses, I do have to say that I don't use Mach-II and didn't really reply to your original item with it in mind. Sorry 'bout dat chief.
-Kevin > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kevin J. Miller > Sent: Monday, September 06, 2004 10:28 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] singleton pattern > > > 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] > ---------------------------------------------------------- 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]
