While I am not sure that what you are asking to do isn't breaking
encapsulation - because your classes shouldn't need to know about the
global scopes to work  (and while I haven't bothered trying to test
what you are saying - i.e. that the global scopes aren't available
from in a CFC - which I am sure they are because I used to break the
rules and access them directly)......

The way I would suggest you could do this - and make it reasonably
"tidy" would be to create a struct out in your page and initialise it
with all the scopes. E.G...

<cfscript>
   allScopes = StructNew();
   allScopes.application = application;
   allScopes.session = session;
   allScopes.variables = variables;
   allScopes.request = request;
   // etc....
</cfscript>

And then have an init() method in your class and pass the "allScopes"
variable over and store it inside your classes instance variables
space (however you manage that).  Then, for the life of the object, it
has access to all the global scopes - but it doesn't actually know
they are "global".

I use a method like this when I want "session" persistence - I just
pass over a reference to some variable I have created in the Session
scope.  My class doesn't know where it has come from - it just knows
that's where it has to store stuff for it to be persistent across the
session.

Hope that idea helps.

Regards,
Gary Menzel



On Thu, 05 Aug 2004 15:10:36 -0400, Mike Chabot <[EMAIL PROTECTED]> wrote:
> Does anybody know if it is possible to access the variables scope of the
> calling page from within a CFC? You can do this with a custom tag using the
> caller scope. I tried to create an error hander inside of a CFC that dumps
> out all the scopes, but I ran into a hurdle because all the error
> information is in the variable scope of the page that had the error.
> 
> The only way around this problem that I have found, short of abandoning the
> CFC idea, is to pass the variables scope into each CFC function call and
> append it to the CFC's variables scope. However, this work-around to too
> annoying to implement. I think the best solution will be to convert the CFC
> to a cfinclude function library, but I thought I would first check to see
> if I am missing something obvious.
> 
> I'm using CFMX 6.1.
> 
> Thank you,
> Mike Chabot
> 
> ----------------------------------------------------------
> 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]

Reply via email to