ColdFusion Scope Existence During Various Request Types And Events

It's a bit OT, but what's the deal with using this.X() to call methods in your CFC? You should just be using X() to call methods defined in the same CFC. When you do this.X(), it acts as an 'outside' call, so if X had access=private, you would actually be blocked.

I like scoping too as well - but this just seems like a mistake. It's like using your phone to call your wife when she is sitting next to you in the room. If you want to use name/val pairs for a local method and you can't do variables.x(....), then you could always use cfinvoke method="X". Its a lot more typing though.

This REALLY bugs me - talk about emotional though - and OT to this entry, which is pretty darn interesting.

Thanks Ben, a really useful summary.

aw, you forgot to test flex2gateway and flashservices calls
I didn't even realize there was such a thing as 'flashservices' until my app started getting errors about Session scope not existing.

It gets a little more complicated, its a request made from either Flex/Flash to domain.com/flex2gateway/
Or in my case, flash media server to /flashservices/gateway/
And with your test files, it was easy to test my situation:
(Sorry for the long post)
+--- PseudoConstruct -----------------+
APPLICATION :: No !!!!!!
SESSION :: No !!!!!!
CGI :: Yes
REQUEST :: Yes
FORM :: Yes
URL :: Yes
COOKIE :: Yes

+--- OnApplicationStart -----------------+
APPLICATION :: Yes
SESSION :: No !!!!!!
CGI :: Yes
REQUEST :: Yes
FORM :: Yes
URL :: Yes
COOKIE :: Yes

+--- OnSessionStart -----------------+
APPLICATION :: Yes
SESSION :: Yes :: 58000 :: 98049968
CGI :: Yes
REQUEST :: Yes
FORM :: Yes
URL :: Yes
COOKIE :: Yes

+--- OnRequestStart -----------------+
APPLICATION :: Yes
SESSION :: Yes :: 58000 :: 98049968
CGI :: Yes
REQUEST :: Yes
FORM :: Yes
URL :: Yes
COOKIE :: Yes

What other 'magic urls' does CF have?

Not sure if this is what you meant or not, but we pass Client variables to our Flex2Gateway to maintain session, and this seems to work like a charm.

Useful stuff as always, Ben. Since this may serve as a bit of a compendium for some, I would think a couple other rather common scenarios worth pointing out would be 1) a CFHTTP invocation of a CFC (or the equivalent in other languages calling into a CF page), and 2) an Ajax call to a CFC.

In case 1), I'm referring to how one might call a CFC like your first attempt (/Test.cfc?Method=Test) via a URL from a programmatic client like CFHTTP (versus a programmatic client calling via soap). In terms of variables present, I suspect it would act like your invocation of it as a soap web service, in that it too would not have the client/session id cookies passed in, unless one manually added them using CFHTTPPARAM (or the equivalent if calling from another language).

In case 2), I suspect it may act more like your first call (from a browser), since Ajax requests also come from a browser and therefore should present the cookies. I'll let others with more experience with different Ajax frameworks speak up on any variations they may have noticed.

I've not noticed how either respond with respect to FORM variables, so if you or anyone else runs a test, it would be good to drop a comment here. As it is, I was just checking in on some things quickly while on vacation. Happy holidays, all.

Re: the difference between cfhttp and ajax requests. Ajax requests should have the cf cookies attached and so will have session (and client) scope variables.

To clarify: AJAX communication to a CFC (let's say with jQuery), would only have access to the application and session scopes if the CFC resides in the same application folder right?

Related question: Assuming the CFC is within the same application, is it a horrible idea to directly access the user's session scope from the CFC methods when handling an AJAX request?

Normally, to follow standard OO best practices, a CFC's methods should only handle arguments passed to it… but in the case of an AJAX request, the Javascript client request doesn't know about the user's Coldfusion session scope natively. may not be safe to have Coldfusion pass those vars to the client, just so they can be sent back to the CFC.

I would love to hear your thoughts on this topic if you get the opportunity.

@Dan:

"AJAX communication to a CFC (let's say with jQuery), would only have access to the application and session scopes if the CFC resides in the same application folder right?"

Please remember - the web server has no concept of AJAX. AJAX is just HTTP via JavaScript. Therefore, the 'rules' here are no different.

"Assuming the CFC is within the same application, is it a horrible idea to directly access the user's session scope from the CFC methods when handling an AJAX request?"

I've blogged on this before - in my opinion, there is nothing wrong with a "Service" CFC directly accessing these scopes. As we all know, CFC creation can be slow, and it can be complex. If you have gone through the trouble of using something like ColdSpring to set up the CFCs, it is silly not to provide access to them via the scopes and your service CFC. (In fact, ColdSpring supports generating these service objects for you.)

My 2 cents.

I am having trouble making a variable, which is part of a returned structure, available to another cffunction in the same component (in CF7).

If I refer to a cfset that creates a randomID, the call gets made twice. Once in the first cffunction and again in the second so the randomIDs will never match.
But then I can't figure out how to get the randomID out of the structure being returned by the first cffunction to compare it against the randomID being returned by the argument. RandomID is in the structure which is
<cfreturn returnStruct />

I have tried setting the scope to THIS, VAR and VARIABLES to no avail. Any help or pointers somewhere would be appreciated.

Sorry, I had some trouble posting. Here is an example of the code:

<cfcomponent>
<cfset myRandomID = CreateUUID()>
<cffunction>
<cfscript>
returnStruct = StructNew();
StructInsert(returnStruct, "message", "XXX");
StructInsert(returnStruct, "randomID", myRandomID);
</cfscript>
<cfreturn returnStruct />
</cffunction>

<cffunction>
<cfargument name="randomID" type="string" required="true">
<cfif #arguments.randomID# is #myRandomID#>
Yes
<cfelse>
No
</cfif>
</cffunction>
</cfcomponent>

Can you post the code that calls your CFC?

I suspect you are creating a new copy of the CFC each time you call it and so the creation of the random number happens each time.

You have to instantiate the cfc into a variable and use it twice so that it is only created once.

Since there is more than one way to skin this cat, post your calling code and I will try and indicate where you should change it.

Ah-ha. Thanks Kevin.

The calling code calls the two methods (though I didn't name the cffunctions in my code above).
So...
<cfinvoke
webservice="http:something.cfc?wsdl"
method="FirstMethod"
returnvariable="returnStruct"
>
<cfinvokeargument name="foo" value="#foo#" />
</cfinvoke>

Do stuff here.

<cfinvoke
webservice="http:something.cfc?wsdl"
method="SecondMethod"
returnvariable="success"
>
<cfinvokeargument name="randomID" value="#returnStruct["randomID"]#" />
</cfinvoke>

Thanks again for helping.

Ahh!

Are you really calling the functions from another machine? That makes it way more complex!

So first let assume you are calling the CFC from the same machine. You would have to write something like this:

-------------------------
<cfobject type="component" component="path.to.my.something" name="myComponent">

<cfinvoke
component="myComponent"
method="FirstMethod"
returnvariable="returnStruct"
>
<cfinvokeargument name="foo" value="#foo#" />
</cfinvoke>

Do stuff here.

<cfinvoke
component="myComponent"
method="SecondMethod"
returnvariable="success"
>
<cfinvokeargument name="randomID" value="#returnStruct["randomID"]#" />
</cfinvoke>
--------------------------

The first <cfobject> tag instantiates the component putting it into memory and then it is called twice using its name by the <cfinvoke> tags.

Ok that's all straightforward but when you call it as a webservice its much more difficult since you have to put it into memory on the remote machine and then call it twice remotely which you can't do directly.

To put it into memory you would normally write someting in the Application.cfc like:

--------------------------
<cfobject type="component" component="path.to.my.something" name="Application.myComponent">
--------------------------

Now the component is in application memory but you can't call it remotely, you have to write a new proxy component to call it and call the proxy remotely.

---------------------------

<cfcomponent>

<cffunction name="function1">
<cfinvoke component="Application.myComponent" method="function1">
</cfinvoke>
<cfreturn returnStruct />
</cffunction>

<cffunction name="function2">
<cfargument name="randomID" type="string" required="true">
<cfinvoke component="Application.myComponent" method="function2">
<cfinvokeargument name="randomID" value="arguments.randomID">
</cfinvoke>
</cffunction>
</cfcomponent>

---------------------------

Now you call the proxy as a webservice like you tried earlier....

Kevin

"I see" said the blind man as he picked up his hammer and saw.

This is intended to be a web service that will be called by a vendor using .Net. I created the calling template for testing purposes.

These revelations lead me to believe I should change my approach and temporarily store that randomID in a database so I can refer to it in the second method with a query.

Thanks again for the help and the education!

Hi Ben,

When you heard the comment "the "APPLICATION" scope doesn't exist during a web service call", that probably wasn't synonymous with "Application.cfc methods aren't triggered during a web service call".

What the person most likely meant was that they couldn't reference the application scope from within the webservice.

For instance, if you were to change your remote Test() method to reference application.applicationName and run the same test, you should see "APPLICATIONNAME is undefined in APPLICATION".

Example:

<cffunction
name="Test"
access="remote"
returntype="string"
returnformat="json"
output="false"
hint="I return a value.">

<cfreturn application.applicationName />
</cffunction>

At least, that is what happens for me... if it isn't for you, please let me know. The ability to reference application.applicationName from within a CFC would solve a problem I am trying to figure out now.

As it turns out, someone put a rogue (empty) application.cfm a couple directories up from my web service CFC.

Obviously, that is why the app scope was not available to it.

Oops :-)

@Ben,

"Yo, is your avatar from The Last Dragon? ... "Who's the master!!!""

Sho-nuff... and SHO-NUFF! :-p

For the life of me, using CF8 at work, the Request Scope simply IS NOT available when I am calling a CFC via AJAX.

I've had to jerry-rig by having the Calling page send a variable which is the Request-scope variable I want to maintain all the way through the AJAX call and back. I really hate that I've yet to comprehend why the scope variables disappear on me.