Hi Ben, Definitely helps - many thanks (P.S. if you'd ever like to discuss any of this stuff over coffee let me know - I work downtown and live in Queens so I go past 14th st twice a day!).
I believe Rob and Haikal were talking about a Singleton for instantiating the page - you are right that the n-pages themselves are not singletons at all - just pbjects in application scope. I have used PageService as the application scoped Singleton for instantiating the page objects and if I add locking that will work fine. Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Nadel Sent: Tuesday, February 28, 2006 7:43 AM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Lazy Load - any patterns to encapsulate? I am new to all this, but if you stand back and think about this whole singleton approach, doesn't it just seem funny: Having lots of singleton instances ???? It almost seems contradictory. To me, it sounds more like you are just having many instances of the Page class. Yes, maybe they are unique... But singleton doesn't sit right in my stomach. What I would do is have a PageCacheController (or something like that) which IS a singleton, and then use that to store/get page data. // Assuming PageCacheController is stored in application scope. // Call page cache content. APPLICATION.PageCacheController.GetFileByPath("blah.cfm"); ... Inside the cache controller.... Function GetFileByPath(strPath){ if (NOT StructKeyExists){ <cflock .... /> if (NOT StructKeyExists){ VARIABLES.Cache[strPath] = CreateObject("PAGE").Init(...) } } // At this point, should have cached page... Return it. Return( VARIABLES.Cache[strPath] ); } Perform a double-lock check for page existence, then return the page object. This is just rough code... But maybe it helps. ...................... Ben Nadel Web Developer Nylon Technology 6 West 14th Street New York, NY 10011 212.691.1134 x 14 212.691.3477 fax www.nylontechnology.com "Some people call me the space cowboy. Some people call me the gangster of love." -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Munn Sent: Tuesday, February 28, 2006 4:05 AM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Lazy Load - any patterns to encapsulate? Yes, that's what I was getting at, but my brain is a little fuzy at this point! ;-) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Haikal Saadh Sent: Monday, February 27, 2006 11:25 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Lazy Load - any patterns to encapsulate? Rather than having PageSingleton save it's data in application scope, wouldn't it be better to have page singleton save it's data inside it, and have page singleton itself in application scope? so: PageSingleton ========= - Struct pages; ========= + init(String pageFilePath) : PageSingleton getPage(String path): String ========= getPage() would basically check if the page has been loaded into 'pages' (structKeyExists), if so, return it, otherwise load it and return it. Rob Munn wrote: > This looks like the Singleton pattern to me: > > page = > CreateObject("component","prototype.entity.systemsforge.PageSingleton").Init ("#ThisPageFilePath#");}; > > Inside the PageSingleton.cfc init() function you put the logic to > check whether the page exists in your application.page structure, > initialize it if it doesn't exist, and return it. That way the only > place you ever reference the application scope is in PageSingleton. I > can post a clearer code example tomorrow when my brain is less foggy, > but this is the method I learned from others here and it has worked > well for me. > > > > -----Original Message----- > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > *On Behalf Of *Peter Bell > *Sent:* Monday, February 27, 2006 7:58 PM > *To:* CFCDev@cfczone.org > *Subject:* [CFCDev] Lazy Load - any patterns to encapsulate? > > Hi There, > > So, I have a page class that I lazy load to minimize initial > application load time for large sites. However, for performance > purposes, I store each page object once it has been created using > the application scope (I don't have so many instances of the page > class that this would be a problem in terms of memory and each one > is fairly small). > > So, my calling code looked like this: > <cfscript> > // If the page doesn't exist in application scope, initialize it > (lazy load) > if(not isDefined("Application.page.#ThisPageFilePath#")) > {"Application.page.#ThisPageFilePath#" = > CreateObject("component","prototype.entity.systemsforge.Page").Init("#ThisPa geFilePath#");}; > </cfscript> > > That looked plain wrong (seemed to be wrong for anything other > than a page something - e.g. a page service to be worrying about > whether or not a given page had been constructed or not), so I > created an Application.PageService, provided it with a > GetbyFilePath() method and put the above code in there. > > Is this going in the right direction? > > Best Wishes, > Peter > > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the > subject of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by > CFXHosting (wwwcfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject > of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org -- Haikal Saadh, Applications Programmer Teaching and Learning Support Services K405, Queensland University of Technology, Kelvin Grove Campus [EMAIL PROTECTED], 3864 8633 CRICOS No. 00213J ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
