>we use the Application.cfm to copy it over to >request scope as a snapshot of the data at that >point (any changes to the kernel will be picked up >on the next request)
If you are doing it like <cfset request.kernel = server.kernel />, the above is not true. CFCs are not "copied"... request.kernel will just hold a reference to server.kernel, and if server.kernel changes (say by a different request), then any requests currently being processed WILL see that change. If you want to copy a CFC, you have to instantiate a new one and copy out the old ones data. Additionally, as a few (including myself) have said, you don't have to instantiate the object in each CFC that uses it. <cfset server.kernel = createObject(...).init(...)/> <cfset whateverScope.myCfc = createObject(...).init(server.kernel)/> Then myCfc can take that argument and assign it into it's variables scope. Remember, it's still just a reference to server.kernel... no additional instaniation (but the same rules about changes apply). myCfc then has no knowledge of where arguments.kernel came from, what scope it's in, etc. -Dave >>> [EMAIL PROTECTED] 07/13/04 2:55 AM >>> ahhhh... well, I'm sort of there. I realise that there should not be ANY reference to session or Application scope within the CFC because those shared scopes can get changed from external influences. to be honest, I thought request and server were, perhaps, excusable. obviously not. we're trying to introduce a "kernel" idea as a central point for getDSN(), error reporting, setup settings and in this case utils. stored in server scope, the app MUST NOT run without this singleton object existing. the kernel is created only in one spot and any changes have to go thru only one path. Every other CFC can rely on this kernel for what it needs on a global level. we use the Application.cfm to copy it over to request scope as a snapshot of the data at that point (any changes to the kernel will be picked up on the next request) is it really that bad to bend encapsulation this way? or is there a better way to use this kernel CFC? >>>> <cfreturn request.kernel.utils.arrayostructs(qry) /> >>That's a violation of encapsulation, plain and simple. >>Something Barney and I wouldn't do understood because at that point the CFC is referencing an external scope. But how would be the best way to use such a util function? Instanciate it in the INIT() of every CFC wanting it? thanx barry.b > Forgive me Sean but I can't see the problem. It's one of those things that really can't be explained if you don't 'get' it... encapsulation is a good thing... it helps you build more reusable code. Referencing external stuff (like request scope or server scope) from inside an object is a violation of encapsulation. That's just a fact. Whether or not that violation of encapsulation is important to you depends on how much you value encapsulation. If you don't 'get' encapsulation then you won't value it so it's kinda moot... > <cfreturn request.kernel.utils.arrayostructs(qry) /> That's a violation of encapsulation, plain and simple. Something Barney and I wouldn't do because we value the benefits of encapsulation but something that others would do if they don't yet view encapsulation as important. > but isn't instanciation of objects a performance hit? Depends. And even if it is, the performance hit may well be irrelevant compared to the benefits of maintaining encapsulation. It's that old saw about never optimize unless you know you have a problem and you've tracked it down to something specific... -- _______________________________________________ Talk More, Pay Less with Net2Phone Direct(R), up to 1500 minutes free! http://www.net2phone.com/cgi-bin/link.cgi?143 ---------------------------------------------------------- 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]
