If you have started working with ColdFusion custom tags, you probably have used the CFAssociate tag. This tag stores the current custom tag's ATTRIBUTES scope in an array of the associated tag. But what happens if you want to store more than just the ATTRIBUTES scope? What happens if you want to store a pointer to each nested tag within the parent tag?

This type of full communication can be done through the GetBaseTagData() method. GetBaseTagData() takes a base tag name (and optional instance number) and returns a pointer to the base tag's VARIABLES scope. This VARIABLES scope, in turn, gives you access to the THISTAG, ATTRIBUTES, and CALLER scopes of the base tag. Once we have this, we can easily store things in the parent tag (base tag) from within the child tag (nested tag).

As a simple experiment, I have parent tag that has one level of child tags. Each child tag stores itself within the parent. Then, once the parent tag is done executing, it just outputs the number of child tags that it has encountered. Here is the demo:

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

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

<!--- Define the parent tags with 5 children. --->

<tag:parent>

<tag:child />

<tag:child />

<tag:child />

<tag:child />

<tag:child />

</tag:parent>

Not much going on there. Now, let's take a look at the Parent tag (parent.cfm):

<!---

Check to see which execution mode the tag is running in.

We won't have access to the child tag data until we are

in the End tag mode.

--->

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

<cfcase value="Start">

<!---

Define the array or children. This array will be

populated by the child custom tags.

--->

<cfset THISTAG.Children = ArrayNew( 1 ) />

</cfcase>

<cfcase value="End">

<!---

At this point, all of our nested Child custom tags

will have executed. Output the number of children

that we have nested. Since each child tag appends

itself to the Children array above, this should

be an accurate number.

--->

<cfoutput>

I Found #ArrayLen( THISTAG.Children )# Children.

</cfoutput>

</cfcase>

</cfswitch>

Again, not much going on here. In the Start mode of the parent tag, we are creating an array to hold pointers to all of the child custom tags. Then, in the End mode of the parent tag, all we have to do is echo out the length of that children array.

Running the above, we get the following output:

I Found 5 Children.

It works nicely. Now, let's take a look at the Child tag to see how each child is subsequently updating the parent's tag data:

<!---

Check to see which execution mode the tag is

running in.

--->

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

<cfcase value="Start">

<!---

Get the parent tag, which is our base tag. Remember

that even though our file name is "parent.cfm",

since it is being used as a custom tag is uses the

"cf_" notation and not file extension.

--->

<cfset THISTAG.Parent = GetBaseTagData( "cf_parent" ) />

<!---

Add child to parent's child array. By adding the

VARIABLES scope, we will be giving the parent tag

access to every aspect of this tag including the

ATTRIBUTES, CALLER, and THISTAG scope.

--->

<cfset ArrayAppend(

THISTAG.Parent.THISTAG.Children,

VARIABLES

) />

</cfcase>

</cfswitch>

Here, the child is getting a pointer to the base tag's VARIABLES scope using the GetBaseTagData() method. Remember that since the VARIABLES scope is a ColdFusion struct it is passed by reference, not by value. That means that we are now sharing the VARIABLES struct with the base tag - we do not have a copy of it. Once we get this pointer, we just append the current child tag's VARIABLES scope to the Children array that we defined in the Start mode of the parent tag.

Using the GetBaseTagData() we can really get a good bidirectional chain of communication. With the pointer we get from the GetBaseTagData() call, we can communicate with the base tag. Then, with the VARIABLES pointer we are storing back into the parent tag's memory space, the parent tag can easily communicate with the child tags.

One word of caution here: This storage creates circular object references; the parent tag now has pointer to the child tags, each of which have a pointer to the parent, which has pointers to the child tags, each of which have a pointer to the parent... etc. etc. etc. What this means is that if you try to CFDump out ANY of this stuff, you will kill your stack and possibly bring down your machine :) Ok, maybe that's a bit dramatic, but please, if you do use CFDump with this kind of experiment, be sure to use the TOP attribute - this will limit the damage that can be caused by the infinite level of dumping.