There's some great stuff here, though not entirely technically correct.

Key/values placed in the Variables scope are not a part of the Request
scope. You can see this by dumping the Request scope and the Variables
scope. You will see that they are two entirely different animals (BTW,
you should also scope query names). Items placed in the Variables scope
can exist beyond the request. An example of this might be within a
persistent object. Say you have a User object that you initialize in
your Session during onSessionStart(). Within this object you have a
struct, Variables.instance, containing several key/value pairs (first
name, last name, userid, etc). This is maintained from request to
request, being globally available to every method within the User object.

Some time back, I started some debate on proper usage of Request vs
Variables, basically stating that you should only use the Variables
scope within a cfc or custom tag. In those use case scenarios, items in
the Variables scope only exist within those objects, and only within the
lifetime of those objects. If you use the Variables scope within a
custom tag, items in that scope are only available to the tag itself,
just as items in the Variables scope of a cfc are only available to the
cfc. The Request scope, however, is available to all objects called in a
request (though I would not suggest direct reference, ever, but rather
passing in data that might be needed).

http://blog.cutterscrossing.com/index.cfm/2009/8/6/Scope-Usage-and-Application-Scaling
http://blog.cutterscrossing.com/index.cfm/2009/8/10/Request-vs-Variables--Which-is-right

The comment threads on each provide a lot of insight as well.

Steve 'Cutter' Blades
Adobe Community Professional
Adobe Certified Expert
Advanced Macromedia ColdFusion MX 7 Developer
____________
http://blog.cutterscrossing.com


Co-Author "Learning Ext JS 3.2" Packt Publishing 2010
https://www.packtpub.com/learning-ext-js-3-2-for-building-dynamic-desktop-style-user-interfaces/book

"The best way to predict the future is to help create it"


On 5/18/2011 7:03 PM, Judah McAuley wrote:
>  I'm going to jump in on the side of variable scoping for another
>  excellent reason: programmers don't tend to use words precisely and
>  that ends up with confusion. When we say:
>     variables.foo = 'bar';
>
>  we are not setting a "local" variable. We're setting a key and value
>  in the variables scope which lives in the request scope.
>
>  When we say (in CF9 and Railo 3.x):
>     var foo = 'bar';
>  or
>     local.foo = 'bar';
>
>  we are setting a key and value in a scope that is local to the
>  function (if we are inside one) that cannot be seen outside of that
>  function. If we set variables.foo (I believe) inside a function it
>  will be a request scoped variable and available to access outside that
>  function.
>
>  And if we just say:
>    foo = 'bar';
>
>  the behavior depends on whether you are inside a function or outside a
>  function and which version of CF/Railo you are on and, if I recall my
>  Railo settings correctly, the default behavior can be switched around
>  in the administrator as to what scope unscoped variables will end up
>  in. Which, of course, means that your code may not even run the same
>  on a production server as it does on your dev box.
>
>  So, in short: If you scope your variables, they should work the same
>  everywhere. If you do not, they *may* work the same but then again
>  they may not. So scope your variables so they aren't so variable :)
>
>  Judah
>
>  On Wed, May 18, 2011 at 12:23 PM, Mike Chabot<mcha...@gmail.com>   wrote:
>>  Always scope your variables, unless you have a specific reason not to. It
>>  reinforces a good habit and demonstrates to anyone reviewing your code that
>>  you know what scoping variables is all about. I would estimate that roughly
>>  100% of experienced CF programmers would agree that scoping local variables
>>  does more good than harm. Even though scoping local variables doesn't add
>>  much value to the Web site, it does help separate you from the masses of
>>  inexperienced CF programmers, and that is enough of a reason to do it.
>>
>>  -Mike Chabot
>  

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive: 
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:344694
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm

Reply via email to