> <cfset request.kernel.utils = server.kernel.utils> this doesn't copy anything, it just makes a reference to server.kernel.utils.
> <cfreturn request.kernel.utils.arrayostructs(qry) /> this breaks encapsulation, as the CFC is now talking to a external scope. As mentioned , the best way to do this is to pass server.kernel.utils into your persistant CFC's constructor, assign into the variables scope (it's still just a reference), and then: > <cfreturn variables.utils.arrayostructs(qry) /> make sense? -Dave >>> [EMAIL PROTECTED] 07/09/04 11:13 AM >>> >> Yeah, and the example you then give shows exactly why you should NOT use cfinclude inside a method! LOL! I can't win. that FourQ example was written by people with far more knowledge and talent than I. It's included just to prove it can be done, but yeah, I'd never do it either... I was looking at FourQ on how to cater for multiple db vendors (whoops! wrong thread...) >> And as Barney says, this will cause any CFCs using such beasts to break encapsulation unless you pass the singleton in as a reference at initialization and save it as an instance variable. Forgive me Sean but I can't see the problem. Maybe I'm thinking too much in VB/ASP mode (eg: I'd be more worried about threading than breaking encpsulation). we've got a kernel that the app works with (the "environment" perhaps?). it instanciates one utils object that gets copied over to request scope in the Application.cfm <cfset request.kernel.utils = server.kernel.utils> and in the persist CFC... <cfreturn request.kernel.utils.arrayostructs(qry) /> (although I see your point about passing in reference and saving it in the CFC's variables scope - I'll bring this up with the guys. We're still keen to use the server scope for our kernel, though) if for some reason the kernel does NOT exist, the app should not run. it holds all app-specific data and methods and we're also caching as many objects as possible at server scope. >> Frankly, you might just as well just call the utility CFC statelessly (via <cfinvoke>)... but isn't instanciation of objects a performance hit? and therefore it's better to cache them when you can, if it's a util used by dozens of other CFC's? Isn't that one of the features of Robin Hilliards "Autobean" project? >> There is a very useful "search" feature back at the www.cfczone.org website. PLEASE don't make us go through all this again ;-) agreed. anyone want to change the thread? I'd be keen to find out why Barney and Sean (and anyone else with 2cents to share) don't like the above idea. Where DOES one put their controller and persist util methods these days? thanx barry.b -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ---------------------------------------------------------- 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]
