How do I determine the context in which a ColdFusion object resides?

Question

So, given that I have an instance of this component:

foo.cfc

<cfcomponent>
  <cffunction name="locateMe">
    <cfreturn "I don't know where I live!">
  </cffunction>
</cfcomponent>

And, this other component, fooParent.cfc:

<cfcomponent>
  <cfset this.foo = createObject("component", "foo")>
</cfcomponent>

Let's say I create instances of "foo" a few different ways:

<cfset myStruct = {}>
<cfset myStruct.foo = createObject("component", "foo")>

<cfset myFoo = createObject("component", "foo")>

<cfset myFooParent = createObject("component", "fooParent")>

<cfoutput>
#myStruct.foo.locateMe()#<br>
#myFoo.locateMe()#<br>
#myFooParent.foo.locateMe()#<br>
</cfoutput>

As expected, this outputs:

I don't know where I live!
I don't know where I live!
I don't know where I live!

What I want to know is, what can I possibly do within foo.cfc that will tell me something (anything!) about the context in which it is being invoked? Since everything ultimately lives in (at least) a scope of some sort, and all scopes are a kind of object, what I'm saying is that I would really like some way to determine the containing object, from within a given instantiated object. Ultimately, some way of building foo.cfc so that something like this could be my output, from my sample snippet above:

I live within a "class coldfusion.runtime.Struct" instance!
I live within a "class coldfusion.runtime.VariableScope" instance!
I live within a "component cfjunk.fooParent" instance!

Where each of those values might be determined by inspecting the result from passing getMetaData the actual containing object reference.

Update As suggested by Micah in the comments, I've added the "Java" tag to this, since I suspect he could be correct in that the solution may lie in using Java for introspection.

Update

Rather than leave this as what appears to be a purely-academic discussion, let me explain why I need this.

I'm using CFWheels ORM with includes to get back references to my data like so:

var user = model("User").findOne(where="id=123", include="AuthSource", returnAs="object");

This will return to me an object that I can reference like so:

user.id // property of the "User" model
user.reset() // method on the "User" model
user.AuthSource.id // property of the "AuthSource" model
user.AuthSource.authenticate(password) // method on the "AuthSource" model

Now, within my "AuthSource.authenticate" method, I would like to know about the "User" object that I'm contained within. Otherwise, I will end up having to call the function like this, instead:

user.AuthSource.authenticate(user, password) // note the redundancy in the use of "user"

I should be able to rely on the fact that I'm calling the method on the AuthSource model through the User object and actually read from that object from within that method.

Okapi

Great question. I wonder if JAVA might have some introspection like functions for determining this sort of thing. Perhaps you could broaden your question by adding a java tag. – Brow

Why the random downvote on this question? How odd.... – Okapi

Answer 1

Its been a very long time since i've done coldfusion, so forgive my pseudocode, but I think what one normally does in these sort of instances, is have the parent send a copy of itself to the child, when it instantiates the child. This is used in a lot of OOP design patterns where two objects need to communicate with each other both ways, not just the parent calling methods on the child.

so your child class would be defined as something like this:

<cfcomponent>
  <cffunction name="init">
     <cfargument name="parentParam" required="yes" type="object">
     <cfset this.parent = parentParam >
      <cfreturn this> 
   </cffuncton>
  <cffunction name="locateMe">
    <cfreturn "I belong to #this.parent.className# !">
  </cffunction>
 <cffunction name="doOtherStuff">
    <cfreturn "I do stuff with my parent: #this.parent.className# !">
  </cffunction>
</cfcomponent>

and then when you use it...

<cfset myParent.child = createObject("component", "Object").init(myParent) />
#myparent.locateMe()#
#myparent.doOtherStuff()#

parentParam would be a required parameter in a constructor method called "init", so the child always has a reference to its parent. Then all your methods can make use of this.parent to do stuff with it. In my code example, i do #this.parent.className# but have no idea of coldfusion objects have such a property. Probably you can use reflection or meta-programming of some sort to do the same thing.

Please note: from what i gather, coldfusion does not have support for constructors built in, so I'm showing you is a community standard best practice from this site:

http://www.iknowkungfoo.com/blog/index.cfm/2007/8/22/Object-Oriented-Coldfusion--1--Intro-to-Objectcfc

I'm sorry you are doing colfusion by the way... ;)

Poleax

Yes, manually keeping track of a reference to the containing object was my first thought. I was hoping there might be a solution other than that, however. I'll wait a bit and see if anyone else chimes in with a different approach. Thanks, and CF really isn't so bad! – Okapi

One unfortunate result of this approach is that cfdumps of your object become infinite loops. :( – Okapi

ah that makes sense, because each object has a reference back to the other. – Poleax

So if you want to avoid referencing the parent in the child, I think you'll have to use coldfusion's version of reflection, and see if there is a way to find all references to the child object. Not even sure how I would do that in languages i'm more familiar with. I know Coldfusion isn't that bad, I started with it. Beats PHP! :) – Poleax

I'd have to say that the solution here would be the way I would probably look at it. I think the main problem is that within the component you shouldn't really be accessing data outside of the component which rules out directly accessing variables. As far as I can recall the only method would be to pass in the parent scope as detailed here. Out of interest, why do you need to do this? – Scrannel

@Simonatmso.net I've updated my question with a more real-world explanation of why I need this. – Okapi

Answer 2

I've removed all previous as it seemed to not be helpful. Following your later comments the following is a suggestion that I believe may be more down the lines of what you are aiming to do.

// Object
<cfcomponent displayname="Object">
    <cffunction name="init">
        <cfargument name="username" type="string">
        <cfscript>
            variables.username = arguments.username;
            variables.authSource = CreateObject('component','AuthSource').init();
        </cfscript>
        <cfreturn this>
    </cffunction>
    <cffunction name="authenticate">
        <cfargument name="password" type="string">
        <cfreturn variables.authSource.authenticate(variables.username,arguments.password)>
    </cffunction>
 </cfcomponent>

<cfcomponent displayname="AuthSource">
    <cffunction name="init">
        <cfreturn this>
    </cffunction>
    <cffunction name="authenticate">
        <cfargument name="username" type="string">
        <cfargument name="password" type="string">

            .... DO STUFF ...

        <cfreturn ...>
    </cffunction>
 </cfcomponent>

 <cfscript>
    objUser = CreateObject('component','Object').init('SomeUserName');
    // Authenticate
    objUser.authenticate('SomePassword');
 </cfscript>

This way, AuthSource doesn't need to know about the parent object, however at the same time someone authenticating doesn't need to pass in the username again. The Object (parent object) has a wrapper method for authenticate that adds in the username.

Is this of any further assistance?

Scrannel

I appreciate the response, but basically your answer is "It's not a good idea to try to do what you're asking". You may be right, but that's not really an answer to the question. Same with how I could change my real example - I know I can change it to make it work, but that's not really what's at issue. Perhaps it is still a bit of an academic question after all. – Okapi

I can see a use for what you are after - I could make use of the same in the project I am currently working on. The way I worked around it is to pass the parent object in to the child however this as mentioned produces circular references which are problematic when serialising and has lead to requiring methods to keep defining and undefining the parent object references on and off. Could update the example above to illustrate though it'll end up quite similar to that posted by @Poleax – Scrannel

I'm really not worried about what I have to do to work around the issue within my last example - that's pretty easy. It's more a technical question about whether or not I should have to work around it, or whether there is some means of doing the specific technical work of finding the context of a given object from within that object. It is probably best to focus less on the later example and more on the first one (foo.locateMe() etc....). – Okapi

@Jake - Interesting question from a technical standpoint. But I do not think it is possible to easily derive the parent, even in java. (Edit:) AFAIK nothing inherently identifies an object's parent. There is no direct linkage or reference unless you inject one, as others mentioned. ie Like with tree nodes in javax.swing, the parent relationship is managed explicitly. Without a direct reference, you would have to work from the top down to find the parent container. ie Iterate through all variables, in all scopes, via the context. (cont'd) – Tousle

Then knock on the door of each one asking "does my reference live here?". That is obviously a ridiculous alternative to simply passing the object in as a parameter. Yes, the latter feels redundant. But trying to "divine" the parent feels like the wrong approach (if it is possible at all). – Tousle

Answer 3

I know this isn't relevant right now but the next version of CF (Zeus) has a function to do this http://blogs.adobe.com/coldfusion/2011/12/19/coldfusion-zeus-potr-callstack/.

Macintosh

Actually, the call stack is different than what I'm asking for. In my example, each of the three calls to foo.locateMe() all originate from the same location in the call stack, despite all being contained in different objects. That's because call stack refers to the execution path (chains of function calls), rather than the organization of the objects in memory. – Okapi