Often when creating ColdFusion components developers will create a structure to hold component instance data. This data is stored in the components ‘variables’ scope and is therefore available to all methods.
Here is an example from the rooibos component generator:
<cfcomponent displayname="sample" output="false" hint="A bean which models the form."> <!--- PROPERTIES ---> <cfset variables.instance = StructNew() />
Now some of you may be wondering why you would use the extra struct level of ‘instance’ when we already know everything in that struct is in the components instance (variables) scope.
A quick question to Geoff Bowers gave me a few answers.
- It’s obvious everywhere you reference this that it is instance data in the variables scope
- You can dump all the components instance data by using <cfdump var=”#variables.instance#” />. The benefit of this is that only dumping the variables scope will give you a lot more than just your instance data! Think method signatures etc
- You can (if you want) separate ‘types’ of instance data. e.g. you might pass in a DAO or Gateway component and assign it to the variables scope (variables.UserDAO)
Another great example of dumping variables.instance quickly and easily (from the Rooibos generator):
<!--- DUMP ---> <cffunction name="dump" access="public" output="true" return="void"> <cfargument name="abort" type="boolean" default="FALSE" /> <cfdump var="#variables.instance#" /> <cfif arguments.abort> <cfabort /> </cfif> </cffunction>

8 Comments
Another benefit is that it makes it trivial to write a duplication/clone method, or the equivalent of a copy constructor.
Personally, I’d only do this when:
1) I have no control over the names I might be adding to a component (as in a DTO), and want to avoid collisions.
2) I’m swapping entire sets of values (as in a DTO).
3) I’m caching the entire set of values.
Do it for a single object and the performance would be negligible. Do it as a matter of convenience for every component in the system, needed or not, and I suspect that all you’re doing is adding the cost of creating a struct to the already high cost of creating a component.
Glad I’m not the only one doing this!
http://www.pbell.com/index.cfm/2007/6/10/Distinguishing-Properties-from-Methods
I’m not thrilled about instance as the structure name, I’d normally have say a widget bean and inside it have variables.widget = StructNew();
I’ve been doing this for about the last year, but Instead of “instance” i’m using a variable named “self”, i.e.
It’s faster to type than instance.
@Adam
Yeah it’s interesting, I was talking to a colleague the other day about something like that and I was thinking that some things in the community you could say are ’standards’. Naming a variables.instance could be one of those?
I mean, it doesn’t really matter what you call it right? But if other developers are looking at your code and *most* people use variables.instance, does that put more pressure on you to use that defacto standard?
I think that variables.instance is the defacto standard in the CF community. The argument about “self” being shorter to type isn’t a great argument since beans follow such a simple pattern that my tool like Rooibos can easily generation them for you. Nobody should be hand typing beans any more.
anybody here know of a good site to find more info on variables in javascript? I\’ve got this site bookmarked and im gonna keep checking it out, but i still would like to find a site that covers variables in javascript a little more thoroughly..thanks