> It sounds like you'd break encapsulation by directly referencing > application scope inside objectStore. Could you explain what it's > doing that it needs to do that?
The objectstore is basically an object cache for "static" objects that goes along the lines of a singleton pattern -- only one instance of each object is stored in the cache (the application scope); if a given object is requested and doesn't already exist in the cache then the object is instantiated and stored (and returned), else the existing instance is returned. All static objects extend a base.cfc which contains an init() method to allow storing of the DSN and a reference to the instance of the objectStore (which is also stored in the application scope). Basically - yes, it does break encapsulation, but I don't see any other way of doing it? I've tried to "restrict" the breaking by passing the reference and only making calls directly to the application scope from within the objectStore... > If you're placing an instance of the objectStore in the application > scope, I'm not sure why it needs to reference application scope > itself - it will be able to store instance data which will, in turn, > be already application scope. Ah, so you're saying rather than storing the individual instance in the application scope, store them as instance variables of the objectstore. Hmm, that sounds sensible but doesn't get around the page context bug does it? Because the objectStore is held in the application scope, it means that all references to it from another object will be to the instance in the "other" object's original context? Along with this, as a general point, if I create instances and put them in a shared scope and they reference other objects in a shared scope, is there in effect a copy of the objects for each of the "page contexts"? i.e. if I keep doing this (creating more instances on each page request) will this not use up a heck-of-a-lot of memory because we're storing loads of different page contexts...? > If an object in a shared scope needs to reference other objects in > the same (or other) shared scopes, it's probably better practice to > 'register' those objects with it after creation than have it 'know' > about their existence in other shared scopes. Er, huh? :) As a further point, the project I'm developing this for won't be set live until October time so by then we can use RedSky and avoid all page context issues, but it's good to get the base down "properly" in the first place rather than reply on the application engine to take up the slack from my lacking software engineering... ;) Tim. ------------------------------------------------------- RAWNET LTD - Internet, New Media and ebusiness Gurus. Visit our new website at http://www.rawnet.com for more information about our company, or call us free anytime on 0800 294 24 24. ------------------------------------------------------- Tim Blair Web Application Engineer, Rawnet Limited Direct Phone : +44 (0) 1344 393 441 Switchboard : +44 (0) 1344 393 040 ------------------------------------------------------- This message may contain information which is legally privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any unauthorised disclosure, copying, distribution or use of this information is strictly prohibited. Such notification notwithstanding, any comments, opinions, information or conclusions expressed in this message are those of the originator, not of rawnet limited, unless otherwise explicitly and independently indicated by an authorised representative of rawnet limited. ------------------------------------------------------- ---------------------------------------------------------- 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).
