chapter31

development in a land far far away…

at the moment

History is not what happened. History is what was written down.

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:

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):


Related Pages

8 Responses to “Using variables.instance inside your components”

  1. Another benefit is that it makes it trivial to write a duplication/clone method, or the equivalent of a copy constructor.

    Al Davidson

  2. 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.

    Michael Long

  3. Peter Bell

  4. 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();

    jim collins

  5. 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 Ness

  6. @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?

    Michael Sharman

  7. 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.

    Peter J. Farrell

  8. 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

    Variables In Javascript

Leave a Reply