Eric,
I've
run into the page context issue with CFCs in the session or application
scope and I've worked around it by duplicating the request scope into the
"this" scope in the CFC's constructor. Then, any additional calls I
need to make, I simply use CFINVOKE to other non-scoped CFCs and for
those, the request scope will be fully available. I've noticed this bug affects
CFFILE as well. If I have a session scoped CFC and make a CFFILE call, the
file object will not be available to the CFC. I have to encapsulate the
CFFILE call and related operations in another CFC that is invoked each time the
operation is performed. It would appear that this does not affect
performance significantly, if at all.
Bottom
line is the request scope isn't your best solution for
this.
It
is a pretty big bug, but not too difficult to work around. Anyone
know about the progress on addressing this bug? Sean?
Jeff
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davis, Eric
Sent: Friday, March 21, 2003 3:38 PM
To: [EMAIL PROTECTED]
Subject: [CFCDev] Request scope across CFCs
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davis, Eric
Sent: Friday, March 21, 2003 3:38 PM
To: [EMAIL PROTECTED]
Subject: [CFCDev] Request scope across CFCs
I've got a method that basically recurses itself until a query has been completely populated. I'm using a request variable to hold the results through all the successive calls, but getting an error which says the variable is undefined - as it's going through its third (and last) recursion.
Should I be going about this in an entirely different way? Why wouldn't the request variable exist in the third recursion, if I'm creating it in the first?
Anybody got a clue?
Thanks,
ecd.--
Eric C. Davis
Programmer/Analyst I
Georgia Department of Transportation
Office of I.T. Applications
404.463.2860.158
[EMAIL PROTECTED]
