When you are using nested ColdFusion custom tags, you can use the CFAssociate tag to associate the child tags with a parent tag. By default, this tag stores the ATTRIBUTES scope values in the parent tag in an array named AssocAttribs. You can, however, explicitly name the target array using the datacollection attribute.

Now, the ATTRIBUTES structure is meant to hold the attributes that are passed via tag attributes when the tag is invoked. But, ATTRIBUTES, like almost every other structure in ColdFusion, can be modified in any way that the programmer desires. This got me thinking - what if you store a pointer to the current tag in the ATTRIBUTES scope? What does the parent tag see?

To test this out, I have a few nested tags:

<!--- Impor the tag libraries. --->

<cfimport taglib="./" prefix="tag" />

<tag:girls>

<tag:girl

name="Ashley"

hair="brunette"

smile="excellent"

/>

<tag:girl

name="Alex"

hair="blonde"

smile="average"

/>

</tag:girls>

As you can see, there are several Girl.cfm custom tags nested within the Girls.cfm ColdFusion tag. Let's take a look at the Girl.cfm ColdFusion tag to see how it is being associated with the parent tag:

<!---

Check to see in which mode this tag is currently

executing. Most of our actions will only apply to

one of the two action modes.

--->

<cfswitch expression="#THISTAG.ExecutionMode#">

<cfcase value="Start">

<!---

Associate this tag with the girl ColdFusion custom

tag. This will store this tag's Attributes scope

into an array titled Girls in the parent tag.

--->

<cfassociate

basetag="cf_girls"

datacollection="Girls"

/>

<!---

Store a reference to the VARIABLES scope in the

ATTRIBUTES scope. This is *not* what attributes

should be used for, but let's see how it affects

the data collection in the parent tag.

--->

<cfset ATTRIBUTES.TagContext = VARIABLES />

</cfcase>

</cfswitch>

Using the CFAssociate ColdFusion tag, Girl.cfm is associating its attributes with the Girls.cfm tag. We are explicitly telling the parent tag (Girls.cfm) to store these associated attributes in a data array names "Girls." But, then, we do something a little sneaky - we store a VARIABLES pointer right into the ATTRIBUTES scope with the key, TagContext.

Let's see what this does for the parent tag (Girls.cfm):

<!---

Check to see in which mode this tag is currently

executing. Most of our actions will only apply to

one of the two action modes.

--->

<cfswitch expression="#THISTAG.ExecutionMode#">

<cfcase value="End">

<!---

Since we are in the End mode execution of this

tag, we know that the child tags (girl.cfm) have

associated themselves with this tag and stored

their attributes in the Girls array. Dump this

out to see how it works.

--->

<cfdump

var="#THISTAG.Girls#"

label="CFAssociate Data Collection Array"

top="4"

/>

</cfcase>

</cfswitch>

Running the above ColdFusion custom tags, we get the following CFDump output:

When CFDumping out the Girls associate attributes array, each tag as the attribute TagContext which is a pointer to the nested child tag itself. Now, remember, since ColdFusion passes structures by reference, and we passed in the VARIABLES struct (scope), this tag that is showing up in the CFDump provides a direct chain of communication with the nested tag, not a copy of it. The parent tag, at this point, could reach in using the TagContext pointer and manipulate or read the child tag's data, if it so desired.

If you only need the parent tag to be able to reach into the child tag (and not the other way around), this feels like a very elegant solution. It took two tags and a slight misuse of the ATTRIBUTES scope. This seems much better than trying to get the base tag data and storing a reference into that. This just seems somehow more organized.

Just a word of caution: since you are storing a tag pointer into its own ATTRIBUTES scope, this creates circular structure references. If you try to CFDump this out without using the Top attribute of the CFDump tag, you will cause an infinitely looping output (which may crash your machine).

This framework was around long, long ago before CFCs. It was a way to use OO programming in ColdFusion before it had it natively. The way it worked was by using custom tags as classes and methods. Check it out.

That some pretty complex stuff. I just downloaded the files and have been poking around and reading through the getting started. Some very interesting techniques. Thanks, this will definitely get me thinking :)

I am the co-founder and lead engineer at InVision App, Inc — the world's leading prototyping,
collaboration & workflow platform. I also rock out in JavaScript and ColdFusion 24x7 and I dream about
promise resolving asynchronously.