setting variables and using in a custom tag

[ScottNeth]

I am trying to <cfset contractname=&quot;1001&quot;> based on a bunch of <cif> statements from a table of flags, but when I use a custom tag, the value <cfoutput>#ContractName#</cfoutput> won't stick in the custom tag.

Scott Neth
Web Designer/Cyberpunk

 

[csteinhilber]

That's by design.

Custom Tags create their own protected variable scope. So if you did something like:

<CFSET sMyString = &quot;Hello World&quot;>
<CF_MY_CUSTOM_TAG>

my_custom_tag.cfm would not be able to access sMyString directly.

There are two ways you have around this, though. The first is to simply pass the variable into the custom tag via an attribute:

<CFSET sMyString = &quot;Hello World&quot;>
<CF_MY_CUSTOM_TAG theString=&quot;#sMyString#&quot;>

now my_custom_tag.cfm can look at

#attributes.theString#

and the value will be &quot;Hello World&quot;. This is generally the best way to code custom tags.

The other way is to make the custom tag &quot;reach out&quot; and poke into the variable scope of the calling page. You do this by using the CALLER scope.

<CFSET sMyString = &quot;Hello World&quot;>
<CF_MY_CUSTOM_TAG>

now my_custom_tag.cfm can look at

#CALLER.sMyString#

and the value will be &quot;Hello World&quot;. This is less than optimal because it somewhat defeats the purpose and design of a custom tag which is to incapsulate generic code for reuse. You can use the code above on one page, but what if another page you wish to use CF_MY_CUSTOM_TAG on doesn't have sMyString, or you inadvertantly named it something else. Or the page does have sMyString, but what you really wanted to pass to CF_MY_CUSTOM_TAG was another variable entirely.

It's best to maintain a custom tags separate variable scope as much as possible (as if it were a private function). To do this, you pass in variables/values that you want the tag to use as attributes of the tag.




-Carl

 

[imstillatwork]

What about

<CFSET Request.sMyString = &quot;Hello World&quot;>
<CF_MY_CUSTOM_TAG>

???

 

[ScottNeth]

the attribute worked perfectly...this has been something that I should have gotten at a week ago...I really appreciate the help

Scott Neth
Web Designer/Cyberpunk

 

[csteinhilber]

Ahhh... imstillatwork pointed out the REQUEST scope as well. Good catch. The request scope is something new since 5.0... and does work nicely in the right situations.

The request variable scope is persistent for the duration of the request (ie - page load). So the base page can set a request variable and all custom tags, etc, called by that page can access it. You just need to specify the request scope any time you address the variable.

<CFSET Request.sMyString = &quot;Hello World&quot;>
<CF_MY_FIRST_CUSTOM_TAG>
     :
<CF_MY_SECOND_CUSTOM_TAG>

now both my_first_custom_tag.cfm and my_second_custom_tag.cfm can access the variable with

#REQUEST.sMyString#

This is even more useful when the first custom tag needs to set a variable that is shared with the second custom tag (say, a custom tag that sets up a header and another that sets up a footer... and the header has to tell the footer that it's themed in blue, or whatever).

But, again, the more tags share variables outside their private space, the more you open your architecture to failure. If

<CF_MY_SECOND_CUSTOM_TAG>

depends on

<CF_MY_FIRST_CUSTOM_TAG>

to set

#REQUEST.sMyString#

, and a special case presents itself where a particular page doesn't call

<CF_MY_FIRST_CUSTOM_TAG>

, you'd just broken your page, unless

<CF_MY_SECOND_CUSTOM_TAG>

can assume some sort of default.

You just need to be much more careful, and

<CFPARAM>

everything.



-Carl