2

If I have a method in a CFC which needs to call in some legacy code via a module call (to perform some critical functionality) am I at risk for variable "bleeding"? For example:

<!--- in my cfc --->
<cffunction name="myFunc"> 

   <cfset var qData = "">
   <cfmodule template="some_legacy_code.cfm" attr1="hi" attr2="hello">
   <cfreturn qData>

</cffunction>


<!--- in some_legacy_code.cfm --->
<cfquery name="qData">
     select * from x
</cfquery>

<cfset caller.qData = qData>

By using caller.qData in this example am I polluting the variables scope of the calling CFC even though I've var scoped qData?

What is the best way for me to test this bleed over so I can "see it for myself" considering I can't easily readily replicate multiple simultaneous calls from different requests as a real application might encounter?

Thanks for any insight.

Leigh
  • 28,765
  • 10
  • 55
  • 103
Brian FitzGerald
  • 3,041
  • 3
  • 28
  • 38
  • 2
    My guess is that `caller.qData` in the module would refer to `variables.qData` in the CFC. You can dump the variables scope: `` to check and make sure. – David Faber Feb 20 '15 at 14:59
  • Good call and thank you. Figuring out how to test to be certain now, will post an update momentarily. – Brian FitzGerald Feb 20 '15 at 15:01
  • 1
    Hmmm, I guess I could have searched first to find the answer http://stackoverflow.com/questions/7409797/can-cfmodule-return-values-to-callers-local-scope – David Faber Feb 20 '15 at 15:45
  • FYI - Modified the tags to indicate your current app ie CF10 – Leigh Feb 20 '15 at 15:48

1 Answers1

2

Ok, apparently this wasn't as hard to test as I was making it out to be (thanks David Faber for the suggestion). By dumping out the variables scope in the cfc, we can easily see if the cfmodule call is "polluting" the cfc's variables scope. This occurs when the cfmodule uses its own caller scope.

As it turns out, this is easily remedied by "var scoping" any problematic variables in the method before making the cfmodule call. Indeed, this does the trick of preventing the cfmodule variables from bleeding through.

Without the var scoped variables in the method, the bleed over does indeed occur (as expected). This was my hunch, but I wanted to be totally sure considering the implications. Thanks!

Brian FitzGerald
  • 3,041
  • 3
  • 28
  • 38
  • Interesting ... what if you use an explicit `local` scope instead of `var` scoping? And what version of CF are you using (or are you using Railo or Lucee)? – David Faber Feb 20 '15 at 15:21
  • Just tested `local` scope and it behaves the same way as `var` (also protecting from bleed through. I am on ACF 10,0,12,286680 – Brian FitzGerald Feb 20 '15 at 15:25
  • 2
    *dumping out the variables scope in the cf* As a quick test, you also do a `structCount(variables)` at the start and end of a function. If the count increases, you know one or more variables was not local scoped. – Leigh Feb 20 '15 at 15:47