Re: scoping
From my [private] point of view, the scoping of 100% variables is a programming extremism. When some scope is implied, there is no reason to scope variables, unless it is absolutely necessary, like in CFQUERY-related loops, or using functions with side effect(s). Or if this is a policy of your organization (strange places may have strange rules). This is similar to requiring the use of parenthesizes in arithmetic expressions in all cases, instead of relying on defined functions precedence rules. Or to prohibit the use of a++, allowing only the use of a=a+1 in C code for readability reasons. Moreover, I always thought that for a default scope, there is no performance gain, if I use fully qualified references, because the default namespace is always checked first, regradless of what some people say that, if you don't use scoping, some overhead is aways involved. So, I wrote a simple test below. No functions, no CFCs, just plain page code: cfset a=1 cfset b=2 !--- This is how most people would write this --- cfset c=0 cfset stTime=GetTickCount() cfloop index=i from=1 to=10 cfset c=a+b /cfloop cfoutputNo scope: c=#c#, time=#GetTickCount()-stTime#br/cfoutput !--- This suppose to be more readable and safe --- cfset c=0 cfset stTime=GetTickCount() cfloop index=i from=1 to=10 cfset variables.c=variables.a+variables.b /cfloop cfoutputScope: c=#c#, time=#GetTickCount()-stTime#br/cfoutput I would expect exactly the same or, at least, very close results. But, results are so unexpected, that I was clicking the Refresh button of my browser for 10 minutes, like crazy. Non-scoped version ALWAYS runs 5-15 times FASTER than the scoped version! This is on CF8, 32-bit, 4 CPU Dell Server, Windows 2003. Could somebody run this on CF9 32/64 bit? Any ideas, how it can be? Remembering scope precedence rules in CF8, I wrote another test for a function with a side effect. Therefore, the explicit scoping of external references suppose to increase the performance. Right? So, this is the test: cffunction name=test1 cfset var i=0 cfset var stTime=GetTickCount() cfloop index=i from=1 to=10 cfset variables.c=a+b /cfloop cfoutputFunction no scope: #GetTickCount()-stTime#br/cfoutput /cffunction cffunction name=test2 cfset var i=0 cfset var stTime=GetTickCount() cfloop index=i from=1 to=10 cfset variables.c=variables.a+variables.b /cfloop cfoutputFunction scope: #GetTickCount()-stTime#br/cfoutput /cffunction cfset a=1 cfset b=2 cfset c=0 cfset test1() cfoutputc=#c#br/cfoutput cfset c=0 cfset test2() cfoutputc=#c#br/cfoutput Non-scoped version ALWAYS runs 2-3 times FASTER than the scoped one. So, at least on my server, the claim that scoping not only increases readability, but also gives a performance gain looks like not entirely accurate (c). So, scope as less, as you can??! ~| 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:344818 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
Non-scoped version ALWAYS runs 5-15 times FASTER than the scoped version! This is on CF8, 32-bit, 4 CPU Dell Server, Windows 2003. Could somebody run this on CF9 32/64 bit? Exactly the same here under CF9. I inverted the two loops ie: scope first and non-scope second, just in case, and the results are the same : about 250 for scoped and 15 for non-scoped. Any ideas, how it can be? This is weird indeed, I would have expected exacly the same time. The only explanation I can see could be poor programing. I've written or modified at least half a dozen compilers in my career, and I've never seen symbols stored by scope (or type or any sort of other characteristic) first, then by name. Doing so could indeed make scoping a little more efficient. But this is not the way compilers (or interpreters like in the case of CF) are designed. They have an array of all symbols by name, and each symbol has characteristics. Then looking for variables.mySymbol would actually mean look for mySymbol first, there may be several of them, each with a different scope, and then look for the one having scope variables. If the compiler is well designed, symbols will be sorted by name first, then by scope in the order they are searched. Your test prove one thing however: Programing ayatollahs just prescribe great principle they feel are logical, but they don't really know what they are talking about. ;-) ~| 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:344823 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
ALWAYS SCOPE! Quite I've been struggling with a site for a side job and no scoping whatsoever. I'd love to discuss this with the original developer. Although the site is such a kludge I suspect that now this person is a CF hater now. ~| 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:344805 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
I know several CF people who love the language and been making a living off it for around a decade. None of them scope things nor do they even understand what scoping is. On Sat, May 21, 2011 at 4:52 PM, Larry Lyons larrycly...@gmail.com wrote: ALWAYS SCOPE! Quite I've been struggling with a site for a side job and no scoping whatsoever. I'd love to discuss this with the original developer. Although the site is such a kludge I suspect that now this person is a CF hater now. ~| 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:344806 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
I know people who have horrible code readability and been in the same teams for 5-10 years. I have worked with a lot of different teams over the years and most of them the readability of the code appeared to be way down on their lists of things to be done. They quite often would state otherwise but when going through the code itself, their statements did not align up with what they actually did. On Thu, May 19, 2011 at 8:11 PM, Matt Robertson websitema...@gmail.comwrote: is at least as important as the former. And anyone blowing off code readability is going to be on the street looking for a job on a different team. -- --m@Robertson-- Janitor, The Robertson Team mysecretbase.com ~| 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:344744 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
Dave Watts wrote: This is a mistake, unless you've actually decompiled CF or used JVM instrumentation to verify this. It's easy to jump from interface (what you interact with) to a conclusion about implementation (how it works under the covers) but you really don't have enough evidence to do that (and if you did that, I'm pretty confident that you'd be wrong about this speculation, for reasons I'll explain shortly). What we call scopes are just another kind of namespace. Their only job is to control where and when we can refer to specific variables that they contain. Since I have it lying around, have a link: http://www.skydancer.org.uk/namespaces.cfm It's incomplete, and constructed way back in CF7, but I'd expect that it's pretty much unchanged in CF8 and CF9. -- Regards, Pete Jordan Horus Web Engineering Ltd http://www.webhorus.net/ phone: +44 1482 446471 mobile: +44 7973 725120 ~| 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:344747 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Re: scoping
I have no reason for it but this is the one thing I tend to never prefix a scope before when referencing. I often think about it but just never have adjusted my ways. So if I have cfquery name=qryGetData ... I do not do cfoutput#Variables.qryGetData.ColumnName#/cfoutput instead I do cfoutput#qryGetData.ColumnName#/cfoutput I like to think of myself as a scoping Nazi but this one case I slack on. On Thu, May 19, 2011 at 10:29 AM, Steve 'Cutter' Blades cold.fus...@cutterscrossing.com wrote: (BTW, you should also scope query names). . 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 -- Aaron Rouse http://www.happyhacker.com/ ~| 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:344748 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
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 Oh, by the way Steve, I like your Ext JS book. Are you doing a revision for 4? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~| 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:344753 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
Thanks Dave! I'm glad you liked it. Please, call me Cutter. I had to start adding the rest of my name to my signature block, a few years back, because the product team didn't know who Steve Blades was every time I applied for ACP;) Packt has asked me to write the book for v4 on my own (I wrote the final chapters of both previous books), and I'm working on an outline now so we can finalize the contract. Looking at a completely different style with this book. Still covering the core concepts, but also writing it as a step-by-step tutorial, building a small application along the way. Going to be a lot of work, but should also be a lot of fun. 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/20/2011 9:57 AM, Dave Watts wrote: 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 Oh, by the way Steve, I like your Ext JS book. Are you doing a revision for 4? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~| 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:344758 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
On Fri, May 20, 2011 at 4:54 AM, Aaron Rouse aaron.ro...@gmail.com wrote: I know people who have horrible code readability and been in the same teams for 5-10 years. Granted. I should have said 'my' team. If they're working for me they get educated quick or they're gone. -- --m@Robertson-- Janitor, The Robertson Team mysecretbase.com ~| 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:344770 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
On Fri, May 20, 2011 at 8:47 AM, Matt Robertson websitema...@gmail.com wrote: On Fri, May 20, 2011 at 4:54 AM, Aaron Rouse aaron.ro...@gmail.com wrote: I know people who have horrible code readability and been in the same teams for 5-10 years. Granted. I should have said 'my' team. If they're working for me they get educated quick or they're gone. Code readability is a bit of a personal preference though. I have a friend/co-worker who writes very terse code and does a lot of things like nested use of the ternary operator three levels deep and closures within closures. I can read it fine but a lot of other people find it terribly unreadable. It is nicely indented and structured and such but not what a lot of people would consider readable. Standards a good thing though on any team. Jud ~| 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:344796 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
Curiously, I do it the exact opposite way: cfset variables.myVariable = fubar / !--- ensure that I am setting in the variables scope, because there could be a 'myVariable' in another scope --- cfoutput#myVariable#/cfoutput !--- I have just guaranteed that I have variables.myVariable, there is no possibility (afaik) that I could be refering to another 'myVariable'. --- However, I should probably scope both. Dominic On 18 May 2011 19:26, Aaron Rouse aaron.ro...@gmail.com wrote: This is my outlook although I do not do something like: cfset Variables.strBlah = something / instead I do: cfset strBlah = something / But I always would do: cfoutput#Variables.strBlah#/cfoutput or cfif Variables.strBlah IS something Seems to me that is what the original OP is asking about but perhaps I am reading too much into it based upon what I do. This is all in reference to just straight CFM pages. On Wed, May 18, 2011 at 12:40 PM, Maureen mamamaur...@gmail.com wrote: ALWAYS SCOPE! Especially if someone else might have to maintain the code someday. On Wed, May 18, 2011 at 9:51 AM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Er ~| 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:344640 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
You keep saying variables in the local scope. You may want to say the current page because there is a local scope. In functions if you cfset var myvar = something / it is in the local scope and you don't attach a scope to it. I believe in CF 9 they actually added the local scope for this purpose as well. Sent from my iPhone On May 18, 2011, at 9:59 PM, Eric Roberts ow...@threeravensconsulting.com wrote: A good question that was brought up by one of our developers. When you don't scope a var it has to search through the various scopes to find it, in order of precedence. If you are using alocal scope, is there a performance hit if you don't scope it since variables is implied or does it still go into search mode? Also...is this negated of you use a cfset on the top of the page (again...this is only referring to local vars.) Eric -Original Message- From: Eric Cobb [mailto:cft...@ecartech.com] Sent: Wednesday, May 18, 2011 01:36 PM To: cf-talk Subject: Re: scoping Here's my take on it: http://www.cfgears.com/index.cfm/2010/9/22/The-importance-of-proper-variable -scoping Thanks, Eric Cobb http://www.cfgears.com Help me make a difference this summer -http://bit.ly/i8dJvQ On 5/18/2011 11:51 AM, Eric Roberts wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Eric ~| 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:344642 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
There is a difference between local scope and local variables scope which is likely resulting in some confusion. The local scope is what is used inside of a function or CFC and it does not use variables. in front of the variable name. There is a separate scope called variables, often referred to as local variables, where you write variables. in front of the variable name. Earlier I thought you were asking about using variables. in front of the variables scope. If you are asking about the local scope, then yes, you should still define it as being in the local scope, but the reason has little to do with performance and you don't write variables. to scope it. You define the scope of local variables so that you don't write code in a function that accidentally impacts code outside of the function, which can happen if you don't specifically restrict your variable to being local to a function. This is a common problem and it is absolutely a best practice to identify local variables as being local variables. Not doing so is a coding mistake, and one that is quite common. -Mike Chabot On Wed, May 18, 2011 at 9:59 PM, Eric Roberts ow...@threeravensconsulting.com wrote: A good question that was brought up by one of our developers. When you don't scope a var it has to search through the various scopes to find it, in order of precedence. If you are using alocal scope, is there a performance hit if you don't scope it since variables is implied or does it still go into search mode? Also...is this negated of you use a cfset on the top of the page (again...this is only referring to local vars.) Eric -Original Message- From: Eric Cobb [mailto:cft...@ecartech.com] Sent: Wednesday, May 18, 2011 01:36 PM To: cf-talk Subject: Re: scoping Here's my take on it: http://www.cfgears.com/index.cfm/2010/9/22/The-importance-of-proper-variable -scopinghttp://www.cfgears.com/index.cfm/2010/9/22/The-importance-of-proper-variable-scoping Thanks, Eric Cobb http://www.cfgears.com Help me make a difference this summer -http://bit.ly/i8dJvQ On 5/18/2011 11:51 AM, Eric Roberts wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Eric ~| 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:344649 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
That's kinda backwards If you don't specify a scope in your cfset statement, then CF will always put it in the VARIABLES scope. But, if you don't specify a scope when calling the variable (in your cfoutput), then CF will have to hunt down the variable to determine which scope it's in. http://www.cfgears.com/index.cfm/2010/9/22/The-importance-of-proper-variable-scoping Thanks, Eric Cobb ECAR Technologies, LLC http://www.ecartech.com http://www.cfgears.com On 5/19/2011 2:55 AM, Dominic Watson wrote: Curiously, I do it the exact opposite way: cfset variables.myVariable = fubar / !--- ensure that I am setting in the variables scope, because there could be a 'myVariable' in another scope --- cfoutput#myVariable#/cfoutput !--- I have just guaranteed that I have variables.myVariable, there is no possibility (afaik) that I could be refering to another 'myVariable'. --- However, I should probably scope both. Dominic On 18 May 2011 19:26, Aaron Rouseaaron.ro...@gmail.com wrote: This is my outlook although I do not do something like: cfset Variables.strBlah = something / instead I do: cfset strBlah = something / But I always would do: cfoutput#Variables.strBlah#/cfoutput or cfif Variables.strBlah IS something Seems to me that is what the original OP is asking about but perhaps I am reading too much into it based upon what I do. This is all in reference to just straight CFM pages. On Wed, May 18, 2011 at 12:40 PM, Maureenmamamaur...@gmail.com wrote: ALWAYS SCOPE! Especially if someone else might have to maintain the code someday. On Wed, May 18, 2011 at 9:51 AM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Er ~| 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:344655 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
See, depending on what the entire CFM page looked like and it's usage along with what brought me into the code to debug things then I personally may not see that output as obvious. Now I look at it that way because I have inherited code from others who just plain had zero clue about scoping variables. I can even think of times where they had something exactly like you described but they actually were expecting the values from URL.myVariable When you have cfoutput#Variables.myVariable#/cfoutput then I can't see why they'd ever question where is this coming from since the scope tells them right there this is something set locally to the page. But then again when you are dealing with someone else's code then you really have no clue what their understanding of the language was or what their intent was. A cfset variables.myVariable = fubar / and cfset myVariable = fubar / are doing the exact same thing. So to me they both ensure that a myVariable will exist within the variables scope. It's just the output of things that I have found I often need to go hunting to figure out what their intent was. As I said before though, this is just in reference to straight CFM pages. On Thu, May 19, 2011 at 2:55 AM, Dominic Watson watson.domi...@googlemail.com wrote: Curiously, I do it the exact opposite way: cfset variables.myVariable = fubar / !--- ensure that I am setting in the variables scope, because there could be a 'myVariable' in another scope --- cfoutput#myVariable#/cfoutput !--- I have just guaranteed that I have variables.myVariable, there is no possibility (afaik) that I could be refering to another 'myVariable'. --- However, I should probably scope both. Dominic On 18 May 2011 19:26, Aaron Rouse aaron.ro...@gmail.com wrote: This is my outlook although I do not do something like: cfset Variables.strBlah = something / instead I do: cfset strBlah = something / But I always would do: cfoutput#Variables.strBlah#/cfoutput or cfif Variables.strBlah IS something Seems to me that is what the original OP is asking about but perhaps I am reading too much into it based upon what I do. This is all in reference to just straight CFM pages. ~| 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:344656 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
because there could be a 'myVariable' in another scope I think CFSET always set a variable in the variables scope when no scope is specified and do not look in other scopes. Ie: CFSET form.test = form.test CFSET test = test CFOUTPUT form.test = #form.test#BR test = #test# /CFOUTPUT This yelds: form.test = form.test test = test ~| 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:344658 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
VARIABLES is implied when setting a variable, not when calling one. CF will always go into search mode if you call a variable without a scope. In CF 8 it will search 3 other scopes before looking at the VARIABLES scope, and in CF 9 it will search 5 scopes before looking at VARIABLES. Thanks, Eric Cobb ECAR Technologies, LLC http://www.ecartech.com http://www.cfgears.com On 5/18/2011 8:59 PM, Eric Roberts wrote: A good question that was brought up by one of our developers. When you don't scope a var it has to search through the various scopes to find it, in order of precedence. If you are using alocal scope, is there a performance hit if you don't scope it since variables is implied or does it still go into search mode? Also...is this negated of you use a cfset on the top of the page (again...this is only referring to local vars.) Eric -Original Message- From: Eric Cobb [mailto:cft...@ecartech.com] Sent: Wednesday, May 18, 2011 01:36 PM To: cf-talk Subject: Re: scoping Here's my take on it: http://www.cfgears.com/index.cfm/2010/9/22/The-importance-of-proper-variable -scoping Thanks, Eric Cobb http://www.cfgears.com Help me make a difference this summer -http://bit.ly/i8dJvQ On 5/18/2011 11:51 AM, Eric Roberts wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Eric ~| 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:344660 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
Aha, so it is. I always thought that the cfset searched the scopes as well. Just did the following to prove myself wrong: cfset form.fubar = test / cfset fubar = changed / cfdump var=#form.fubar# /cfabort (output = 'test') Oivay! On 19 May 2011 13:47, Eric Cobb cft...@ecartech.com wrote: If you don't specify a scope in your cfset statement, then CF will always put it in the VARIABLES scope ~| 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:344661 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: scoping
Always scope your variables! We used to have a cf programmer around here that used to put the variable level in the application scope. Then he occasionally put it in session scope, occasionally in request scope, sometimes in the variables scope, and even sometimes he would pull a query with level as a column name. Troubleshooting his application was a nightmare because in the output code he would just put #level#. We never knew which scope was actually supposed to be displaying, or which one was without doing extra leg work. Scope everything, be safe, make troubleshooting easier on yourself, and maybe even eliminate some errors by doing it! Steve ~| 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:344664 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
Yes, the real benefit is that you always know which scope is being referenced, with no ambiguity. Actually, there is only ambiguity for those who do not know the language they are using and its rules by default. There could be an ambiguity if you are using the same variables names for different variables in different scopes; now THIS can be considered as bad practice. If you never do this, there will never be ambiguity. For me, always scoping would be the same as always providing all attributes with their default values in all tags. Anyway, NEVER SAY ALWAYS. ~| 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:344670 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Fwd: Re: scoping
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 Chabotmcha...@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
Re: scoping
On Wed, May 18, 2011 at 12:51 PM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? I would ALWAYS scope. Not for style reasons, not for readability vs non-readability, not for speed. I've run into at least one occasion when CF choked and died because of un-scoped variables. In this case it was a long running CF request that used un-scoped variables. In walking through the scopes during an isDefined() call, CF eventually got to the CGI scope, which required CF to make a request back to the webserver (or webserver connector) to see if such a variable existed. Problem was that the connection with the webserver had already been severed (because it was a long running request). So, CF sat and sat waiting for an answer that would never come. Eventually these requests would build up, the server would run out of threads, then it would fall over. Bam. It is true that this is a fairly specific case that may not happen to many people. However, it does serve to illustrate that YOU NEVER REALLY KNOW what strange negative side effect unscoped variables might cause. So - scope it. Always. -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell: 678.637.5072 aim: cameroncf email: cameronc@gmai ~| 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:344697 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: scoping
Does it always search of the variable is not scoped (when calling it) even if you do a cfset at the top of the page? Or does it automagically know it is in the Variables scope? Eric -Original Message- From: Eric Cobb [mailto:cft...@ecartech.com] Sent: Thursday, May 19, 2011 07:47 AM To: cf-talk Subject: Re: scoping That's kinda backwards If you don't specify a scope in your cfset statement, then CF will always put it in the VARIABLES scope. But, if you don't specify a scope when calling the variable (in your cfoutput), then CF will have to hunt down the variable to determine which scope it's in. http://www.cfgears.com/index.cfm/2010/9/22/The-importance-of-proper-variable -scoping Thanks, Eric Cobb ECAR Technologies, LLC http://www.ecartech.com http://www.cfgears.com On 5/19/2011 2:55 AM, Dominic Watson wrote: Curiously, I do it the exact opposite way: cfset variables.myVariable = fubar / !--- ensure that I am setting in the variables scope, because there could be a 'myVariable' in another scope --- cfoutput#myVariable#/cfoutput !--- I have just guaranteed that I have variables.myVariable, there is no possibility (afaik) that I could be refering to another 'myVariable'. --- However, I should probably scope both. Dominic On 18 May 2011 19:26, Aaron Rouseaaron.ro...@gmail.com wrote: This is my outlook although I do not do something like: cfset Variables.strBlah = something / instead I do: cfset strBlah = something / But I always would do: cfoutput#Variables.strBlah#/cfoutput or cfif Variables.strBlah IS something Seems to me that is what the original OP is asking about but perhaps I am reading too much into it based upon what I do. This is all in reference to just straight CFM pages. On Wed, May 18, 2011 at 12:40 PM, Maureenmamamaur...@gmail.com wrote: ALWAYS SCOPE! Especially if someone else might have to maintain the code someday. On Wed, May 18, 2011 at 9:51 AM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Er ~| 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:344708 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
It always searches if the variable unscoped. 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/19/2011 12:38 PM, Eric Roberts wrote: Does it always search of the variable is not scoped (when calling it) even if you do a cfset at the top of the page? Or does it automagically know it is in the Variables scope? Eric -Original Message- From: Eric Cobb [mailto:cft...@ecartech.com] Sent: Thursday, May 19, 2011 07:47 AM To: cf-talk Subject: Re: scoping That's kinda backwards If you don't specify a scope in your cfset statement, then CF will always put it in the VARIABLES scope. But, if you don't specify a scope when calling the variable (in your cfoutput), then CF will have to hunt down the variable to determine which scope it's in. http://www.cfgears.com/index.cfm/2010/9/22/The-importance-of-proper-variable -scoping Thanks, Eric Cobb ECAR Technologies, LLC http://www.ecartech.com http://www.cfgears.com On 5/19/2011 2:55 AM, Dominic Watson wrote: Curiously, I do it the exact opposite way: cfset variables.myVariable = fubar / !--- ensure that I am setting in the variables scope, because there could be a 'myVariable' in another scope --- cfoutput#myVariable#/cfoutput !--- I have just guaranteed that I have variables.myVariable, there is no possibility (afaik) that I could be refering to another 'myVariable'. --- However, I should probably scope both. Dominic On 18 May 2011 19:26, Aaron Rouseaaron.ro...@gmail.com wrote: This is my outlook although I do not do something like: cfset Variables.strBlah = something / instead I do: cfset strBlah = something / But I always would do: cfoutput#Variables.strBlah#/cfoutput or cfif Variables.strBlah IS something Seems to me that is what the original OP is asking about but perhaps I am reading too much into it based upon what I do. This is all in reference to just straight CFM pages. On Wed, May 18, 2011 at 12:40 PM, Maureenmamamaur...@gmail.com wrote: ALWAYS SCOPE! Especially if someone else might have to maintain the code someday. On Wed, May 18, 2011 at 9:51 AM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Er ~| 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:344711 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Re: scoping
Hmm.. I sort of get what you are saying, Cutter, but then it seems like Variables is a scope that can only exist within another scope. If there was a variables.myvars struct in session, I would say that the myvars struct really lives in Session. Yes, it also technically lives inside another structure called variables, but is that a real scope? I think of a scope as having a stronger boundary, perhaps a separate memory pool. Variables, as far as I know, can't persist beyond a single request unless you put it inside some other scope, like Session or Application. Though I do suppose that if you set variables.instance in onSessionStart it would sort of create a pointer in Session that says make variables.instance available in each request tied to this session? Or maybe not. I'll have to give this some more thought. It seems to me that you're right, Variables can be different than Request though often treated the same. Something to ponder when I inevitably wake up in the middle of the night thinking about weird things like this. :) Cheers, Judah On Thu, May 19, 2011 at 8:29 AM, Steve 'Cutter' Blades cold.fus...@cutterscrossing.com wrote: 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 Chabotmcha...@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
Re: scoping
I wouldn't say that the Variables scope is intended to live inside another scope, I think that it's just that it can, in the context of a persistent object. As noted by Ray, in the comments of my first blog post, the Variables scope was kind of an afterthought, giving a way to access those variables that weren't explicitly in another scope (form, url, session, application, request, client). With most of the core of ColdFusion created prior to it's port to Java, or even the thought of OO web application development, I think that many of the scopes kind of came about as an afterthought. Containers, of sorts, to fill specific needs. The Variables scope always existed, it just didn't get the VARIABLES. prefix until MX (if I remember Ray). *The following is deduction, conjecture, and opinion. Discuss freely if you wish, this is just how I see it.* I think that usage of the Variables scope, on a high level, was never well documented. That years and years of examples and sample applications were written without really thinking about what the correct usage of the scope might be. The Request scope, by it's name, appears to be where you would place variables to be used throughout a request. The Variables scope operates very similarly, until you declare them inside a custom tag. A custom tag can directly access a Request scope variable, but Variables declared outside that tag are invisible (without using the CALLER scope). From a timeline perspective, this is important, because custom tags predate cfc's, which have the same constraints. My theory is that Variables were to be used within custom tags only. The problem being, custom tags were just .cfm templates with no way of explicitly declaring them as custom tags (outside of how they were called), and as such any .cfm page could 'do' Variables. Being that many would cfinclude other templates, the included templates would, by process, then be part of that root document and have access to those same Variables. Only when a template was called in process as a custom tag would it not have that access, and that same process now works within cfc's as well. In that manner (and thinking within that context) the Variables scope truly does become a 'scope', as an object global scope, just as the LOCAL scope is now a function local scope. A good way to look at it is to see how and when these variables are accessible: Server, Application, Session, Request, Client, Url, and Cgi scopes are available throughout a request, in the root .cfm doc (including cfincludes), custom tags, and cfc's (this last not suggested, just pass 'em in) (the Form scope might qualify here too, but I've never tried) Variables declared in a root .cfm doc (including cfincludes) are available throughout the request, but cannot be accessed directly by custom tags (without the Caller reference) or cfc's at all (***this usage is what I consider a mistake***) Variables declared within a custom tag are only available within that custom tag (excepting a nested tag using the Caller scope). Variables declared within a cfc are only directly available throughout the cfc. As I put in the second item above, I think the use of the Variables scope, outside of it's encapsulated usage within a custom tag or a cfc, is a mistake. I think it was something that ultimately shouldn't have been possible, and once it was discovered as an issue it was too late to change behavior because of the thousands of applications that would have needed to be refactored. I, personally, have seen large performance gains in both large and small applications by adjusting how I use the Variables and the Request scopes. Some agree with me (having seen it and practicing it themselves), and some do not. I can say this: poor performing CF apps can generally be greatly improved by scoping all variables, paying heavy attention to the db (queries, indexes, execution plans, etc), and tuning the JVM for the application in use. If more CF devs start doing these things consistently we might get rid of some of the bad rap (can anyone say MySpace). Write it to scale, even if it never will. 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/19/2011 3:02 PM, Judah McAuley wrote: Hmm.. I sort of get what you are saying, Cutter, but then it seems like Variables is a scope that can only exist within another scope. If there was a variables.myvars struct in session, I would say that the myvars struct really lives in Session. Yes, it also technically lives inside another structure called variables, but is that a real scope? I think of a scope as having a stronger boundary,
Re: Re: scoping
Hmm.. I sort of get what you are saying, Cutter, but then it seems like Variables is a scope that can only exist within another scope. If there was a variables.myvars struct in session, I would say that the myvars struct really lives in Session. Yes, it also technically lives inside another structure called variables, but is that a real scope? The Variables scope doesn't exist within any other scope. Just because you're using the word variables in a variable name declaration doesn't mean you're using the Variables scope: cfset foo = bar -- using the Variables scope cfset Variables.foo = bar -- using the Variables scope cfset Session.variables.foo = bar -- not using the Variables scope I think of a scope as having a stronger boundary, perhaps a separate memory pool. This is a mistake, unless you've actually decompiled CF or used JVM instrumentation to verify this. It's easy to jump from interface (what you interact with) to a conclusion about implementation (how it works under the covers) but you really don't have enough evidence to do that (and if you did that, I'm pretty confident that you'd be wrong about this speculation, for reasons I'll explain shortly). What we call scopes are just another kind of namespace. Their only job is to control where and when we can refer to specific variables that they contain. Variables, as far as I know, can't persist beyond a single request unless you put it inside some other scope, like Session or Application. As mentioned above, once you do that you're no longer using the Variables scope. And this is true across the board really - if you pass the Form scope into a variable within the Session scope, that variable is not the Form scope - even if it contains the same data that the Form scope contains, even if it was passed to the Session scope by reference. Java, like many other languages, has two containers for runtime information - a stack and a heap. Objects go into the heap. References to those objects go into the stack. A single object can have multiple references, or none at all (in which case it'll be marked for deletion and garbage-collected eventually). If I do this: cfset foo = structNew() cfset foo.bar = baz this creates an object in the heap, and a reference called Variables.foo that will let me retrieve the value of the object. If that's all I did in my page, the reference would go out of scope after the page ran, and the object would eventually be deleted. If I then do this within the same page: cfset Session.foo = Variables.foo this creates a second reference that points to the same object. The first reference would go out of scope after the page ran - I wouldn't be able to use it any more - but the object wouldn't be marked for deletion because there's a second reference that still exists. There's no separate memory pool - the object is stored in the same place in memory for its lifetime (although if it lasts long enough, it may be moved into a longer-lived generation, but let's not get into that right now). And of course, if you were to pass the entire scope as a variable, it would be treated as a structure and would be passed by reference the same way. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~| 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:344723 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
As noted by Ray, in the comments of my first blog post, the Variables scope was kind of an afterthought, giving a way to access those variables that weren't explicitly in another scope (form, url, session, application, request, client). With most of the core of ColdFusion created prior to it's port to Java, or even the thought of OO web application development, I think that many of the scopes kind of came about as an afterthought. Containers, of sorts, to fill specific needs. The Variables scope always existed, it just didn't get the VARIABLES. prefix until MX (if I remember Ray). I'm pretty sure that the name Variables predates MX by at least two versions. The Request scope was introduced in 4.x, primarily for Spectra if I recall correctly - Spectra had a lot of custom tags, and passing variables back and forth from custom tags to their callers is a bit of a pain. I wouldn't be surprised if Variables has always been available as a named scope, and I'm pretty confident it was in CF 3 (which introduced CFML custom tags) - I remember it being in the official Allaire course curriculum. And i don't really think that the Variables scope itself is an afterthought - it's the default scope, and for a long time it really didn't need a name to separate it from the non-default scopes. *The following is deduction, conjecture, and opinion. Discuss freely if you wish, this is just how I see it.* I think that usage of the Variables scope, on a high level, was never well documented. That years and years of examples and sample applications were written without really thinking about what the correct usage of the scope might be. The Request scope, by it's name, appears to be where you would place variables to be used throughout a request. The Variables scope operates very similarly, until you declare them inside a custom tag. A custom tag can directly access a Request scope variable, but Variables declared outside that tag are invisible (without using the CALLER scope). From a timeline perspective, this is important, because custom tags predate cfc's, which have the same constraints. It's very simple - I don't think a lot of conjecture is needed. By default, when you create a variable within a page, it's only available within that page. Before CFML custom tags existed, this wasn't a problem, as there wasn't anywhere else you had to worry about; when you CFINCLUDE one page within another, for all practical purposes you end up with one single page at runtime. But custom tags execute separately from your page - your page halts when the custom tag runs, and restarts when the custom tag has finished running. And CFML has been consistent about this behavior, really. CFCs are separate programs, just like custom tags, so they have their own separate local variables that are referenced using the Variables scope. Functions, on the other hand, are not separate programs, they're embedded within your page (either literally, or via CFINCLUDE) so they share the same Variables scope - and need their own specific function-local scope. My theory is that Variables were to be used within custom tags only. The problem being, custom tags were just .cfm templates with no way of explicitly declaring them as custom tags (outside of how they were called), and as such any .cfm page could 'do' Variables. I don't think that theory is borne out by history. As I put in the second item above, I think the use of the Variables scope, outside of it's encapsulated usage within a custom tag or a cfc, is a mistake. I think it was something that ultimately shouldn't have been possible, and once it was discovered as an issue it was too late to change behavior because of the thousands of applications that would have needed to be refactored. Ugh. No. In general, in any programming language, you want to use the most restrictive scope possible. If you're only going to use a variable within a single page, and not within any custom tags, there's no reason not to use the Variables scope. There's no reason to refactor applications that are doing this. If you're going to use a variable within a page, and you also want that variable to be available to custom tags, then sure, use the Request scope. The key lesson isn't to use Request instead of Variables, it's to know the difference between the two and use each appropriately. I can say this: poor performing CF apps can generally be greatly improved by scoping all variables, paying heavy attention to the db (queries, indexes, execution plans, etc), and tuning the JVM for the application in use. In my experience, the performance improvement you get from scoping variables that are currently unscoped is not usually worth the time to change the application. If you've done things the right way from the beginning, great - but I've yet to see the application where (a) this hasn't already been done, while at the same time (b) the database on the other hand has been perfectly tuned.
Re: scoping
On Thu, May 19, 2011 at 6:55 AM, wrote: Actually, there is only ambiguity for those who do not know the language they are using and its rules by default. The penalty for being smug about your mastery of the universe is - sooner or later - extremely painful. Put simply, unscoped vars can yield uncertain results. There has been more than enough illustration of this with specific cases right here in this thread, so I won't repeat them. Unscoped = sloppy. Always scoped = always predictable behavior, and always traceable at a glance by other members of the team. The latter is at least as important as the former. And anyone blowing off code readability is going to be on the street looking for a job on a different team. -- --m@Robertson-- Janitor, The Robertson Team mysecretbase.com ~| 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:344731 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
Dave, Thanks for chiming in on this, your insight is always helpful. Most of my thoughts there are my own theories, which must be proven (or debunked) to be otherwise :) Your deep knowledge of the history of CF helps to fill in the gaps of time and memory, and keep perspective (for the record, Ray said MX in one of the comments to the first blog post I referenced, but he was guessing because he couldn't remember). As to refactoring along these lines, I guess that really depends on the application. Many applications are relatively small, and serving a single domain. It may not be necessary to put out the effort, in those cases. My original thoughts on this topic came from years of working on a large codebase that concurrently ran 2,000 sites. Unscoped variables were all through, when I got my hands on it, and in the process of scoping (necessary to eliminate bugs, shave off unnecessary scopeCheck, and clarify purpose) we discovered memory leaks in the application. Research, at the time, uncovered several postings around the net on the use of the Variables scope and issues with Garbage Collection, something we were seeing in JVM profiling as well. This was when I started working on this theory and putting it into practice, and we did see a significant performance gain (30%). Apparently I wasn't completely alone. I've found several other developers, at different conferences in discussions, who came to the same conclusions as well. The (possible) memory leak issue does not appear to be an issue anymore. It was submitted to Adobe as a bug for, at least, versions 6, 6.1, and 7, and seemed to have been resolved with the release of version 8 (some profiling tests, run by others, appear to verify that fact). That said, it's a habit now, and one that works well for me (and my variables are always scoped). It also makes sense to me, where naming (of the other scopes) serves some purpose in defining where a particular variable might've be declared. But that's me. Last note, I did forget caching. For many/most/all apps, some form of caching would be critical. Variable scoping, DB performance (queries on up), JVM tuning, and caching. 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/19/2011 5:28 PM, Dave Watts wrote: As noted by Ray, in the comments of my first blog post, the Variables scope was kind of an afterthought, giving a way to access those variables that weren't explicitly in another scope (form, url, session, application, request, client). With most of the core of ColdFusion created prior to it's port to Java, or even the thought of OO web application development, I think that many of the scopes kind of came about as an afterthought. Containers, of sorts, to fill specific needs. The Variables scope always existed, it just didn't get the VARIABLES. prefix until MX (if I remember Ray). I'm pretty sure that the name Variables predates MX by at least two versions. The Request scope was introduced in 4.x, primarily for Spectra if I recall correctly - Spectra had a lot of custom tags, and passing variables back and forth from custom tags to their callers is a bit of a pain. I wouldn't be surprised if Variables has always been available as a named scope, and I'm pretty confident it was in CF 3 (which introduced CFML custom tags) - I remember it being in the official Allaire course curriculum. And i don't really think that the Variables scope itself is an afterthought - it's the default scope, and for a long time it really didn't need a name to separate it from the non-default scopes. *The following is deduction, conjecture, and opinion. Discuss freely if you wish, this is just how I see it.* I think that usage of the Variables scope, on a high level, was never well documented. That years and years of examples and sample applications were written without really thinking about what the correct usage of the scope might be. The Request scope, by it's name, appears to be where you would place variables to be used throughout a request. The Variables scope operates very similarly, until you declare them inside a custom tag. A custom tag can directly access a Request scope variable, but Variables declared outside that tag are invisible (without using the CALLER scope). From a timeline perspective, this is important, because custom tags predate cfc's, which have the same constraints. It's very simple - I don't think a lot of conjecture is needed. By default, when you create a variable within a page, it's only available within that page. Before CFML custom tags existed, this wasn't a problem, as there wasn't anywhere else you
Re: scoping
The (possible) memory leak issue does not appear to be an issue anymore. It was submitted to Adobe as a bug for, at least, versions 6, 6.1, and 7, and seemed to have been resolved with the release of version 8 (some profiling tests, run by others, appear to verify that fact). That said, it's a habit now, and one that works well for me (and my variables are always scoped). It also makes sense to me, where naming (of the other scopes) serves some purpose in defining where a particular variable might've be declared. But that's me. I do remember a problem with passing variables from shared scopes to the Variables scope in CF 6 and 7. But I still think that people in general are better off using the Variables scope where it makes sense, and the Request scope where that makes sense, in the absence of any version-specific bug that makes this untenable. After all, people used to duplicate shared scopes into local variables in CF 5 and earlier to work around locking issues, but just because that arguably* made sense at the time doesn't make it a good programming practice now. But in any case, it seems that this thread is actually covering several different topics. The OP seemed to be asking whether it made sense to use the Variables scope when using CFSET: cfset foo = bar vs cfset Variables.foo = bar and the answer to that seems to me to be, it really doesn't matter as long as you're a competent CF programmer and know that the default scope is Variables. But then, many people seemed to read a bit more into the original question (assuming I read it correctly myself, I guess) and turned it into, should all variable references be scoped: cfoutput#foo#/cfoutput vs cfoutput#Variables.foo#/cfoutput and the answer to that seems to be to me, yes, it's absolutely a good idea to always include the scope in references to variables. Finally, you and I are discussing the relative merits of different scopes, I guess, which is a third topic. * it really didn't make sense at the time, but many programmers found it much easier than locking things throughout the page. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~| 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:344740 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
Local scope is only implied when using cf9 On May 18, 2011, at 11:51 AM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Eric ~| 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:344620 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
Ray Camden has blogged about this in the past, as you can read here: http://www.coldfusionjedi.com/index.cfm/2011/1/26/ColdFusion-and-Unscoped-Variables In summary, there are theoretical performance gains by scoping all variables and there are some security concerns by not scoping vars. Both are discusses in Ray's post. On Wed, May 18, 2011 at 12:51 PM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Eric ~| 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:344621 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
ALWAYS SCOPE! Especially if someone else might have to maintain the code someday. On Wed, May 18, 2011 at 9:51 AM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Er ~| 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:344622 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
This is my outlook although I do not do something like: cfset Variables.strBlah = something / instead I do: cfset strBlah = something / But I always would do: cfoutput#Variables.strBlah#/cfoutput or cfif Variables.strBlah IS something Seems to me that is what the original OP is asking about but perhaps I am reading too much into it based upon what I do. This is all in reference to just straight CFM pages. On Wed, May 18, 2011 at 12:40 PM, Maureen mamamaur...@gmail.com wrote: ALWAYS SCOPE! Especially if someone else might have to maintain the code someday. On Wed, May 18, 2011 at 9:51 AM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Er ~| 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:344626 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
Here's my take on it: http://www.cfgears.com/index.cfm/2010/9/22/The-importance-of-proper-variable-scoping Thanks, Eric Cobb http://www.cfgears.com Help me make a difference this summer -http://bit.ly/i8dJvQ On 5/18/2011 11:51 AM, Eric Roberts wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Eric ~| 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:344627 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
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 On Wed, May 18, 2011 at 12:51 PM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Eric ~| 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:344628 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
+1 for always scoping. Clearer to read, small performance gain, small security gain and why not. On Wed, May 18, 2011 at 3: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 On Wed, May 18, 2011 at 12:51 PM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Eric ~| 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:344629 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
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:344630 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: scoping
So is there any real benefit in using or not using variables. For local variables? -Original Message- From: Maureen [mailto:mamamaur...@gmail.com] Sent: Wednesday, May 18, 2011 12:40 PM To: cf-talk Subject: Re: scoping ALWAYS SCOPE! Especially if someone else might have to maintain the code someday. On Wed, May 18, 2011 at 9:51 AM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Er ~| 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:344631 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: scoping
A good question that was brought up by one of our developers. When you don't scope a var it has to search through the various scopes to find it, in order of precedence. If you are using alocal scope, is there a performance hit if you don't scope it since variables is implied or does it still go into search mode? Also...is this negated of you use a cfset on the top of the page (again...this is only referring to local vars.) Eric -Original Message- From: Eric Cobb [mailto:cft...@ecartech.com] Sent: Wednesday, May 18, 2011 01:36 PM To: cf-talk Subject: Re: scoping Here's my take on it: http://www.cfgears.com/index.cfm/2010/9/22/The-importance-of-proper-variable -scoping Thanks, Eric Cobb http://www.cfgears.com Help me make a difference this summer -http://bit.ly/i8dJvQ On 5/18/2011 11:51 AM, Eric Roberts wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Eric ~| 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:344632 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: scoping
The other camp's argument (for the variables scope): it is not necessary so why do it? Eric (who is in the scope everything camp) -Original Message- From: John Allen [mailto:johnfal...@gmail.com] Sent: Wednesday, May 18, 2011 03:05 PM To: cf-talk Subject: Re: scoping +1 for always scoping. Clearer to read, small performance gain, small security gain and why not. On Wed, May 18, 2011 at 3: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 On Wed, May 18, 2011 at 12:51 PM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Eric ~| 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:344633 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
Yes, the real benefit is that you always know which scope is being referenced, with no ambiguity. On Wed, May 18, 2011 at 6:56 PM, Eric Roberts ow...@threeravensconsulting.com wrote: So is there any real benefit in using or not using variables. For local variables? ~| 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:344634 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping
The variables scope isn't local. It's global to CFC or to the page. On May 18, 2011, at 8:56 PM, Eric Roberts ow...@threeravensconsulting.com wrote: So is there any real benefit in using or not using variables. For local variables? -Original Message- From: Maureen [mailto:mamamaur...@gmail.com] Sent: Wednesday, May 18, 2011 12:40 PM To: cf-talk Subject: Re: scoping ALWAYS SCOPE! Especially if someone else might have to maintain the code someday. On Wed, May 18, 2011 at 9:51 AM, Eric Roberts ow...@threeravensconsulting.com wrote: We had a discussion at work as to whether or not we should scope local vars with the variables. scope since that is implied in a cfset. One camp says it is not needed because of the implicit scoping when using cfset...the other camp says it is better to tack on variables. and make it explicit for security and readability. Any thoughts? Er ~| 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:344635 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: scoping and speed
In theory, yes, as ColdFusion will have to hunt through the various scopes to find the exact variable that you're referencing. Whether it's noticeable or not.. hard to say. From the CF8 docs ( http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Variables_32.html ): Because ColdFusion must search for variables when you do not specify the scope, you can improve performance by specifying the scope for all variables. I do actually recall hearing that on Railo, it was faster to -not- scope local variables. Not sure if that still holds true or not. On Thu, Dec 10, 2009 at 7:13 AM, Chad Gray cg...@careyweb.com wrote: If you don't scope your local variables does the page run slower? IE. #variables.foo# vs. #foo# ~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:329047 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: scoping and speed
Funny thing is, even when I have specified scope for all my variables, I've still seen ColdFusion stack traces hunting around for scopes. However, please note this was a very intense script trying to calculate all prime numbers between 0 and 10,000,000. For the other 99.% of ColdFusion code out there, do what creates the most manageable, self-documenting code. The performance results will most likely be negligible. ~Brad Original Message Subject: Re: scoping and speed From: Charlie Griefer charlie.grie...@gmail.com Date: Thu, December 10, 2009 9:59 am To: cf-talk cf-talk@houseoffusion.com Because ColdFusion must search for variables when you do not specify the scope, you can improve performance by specifying the scope for all variables. ~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:329054 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: scoping and speed
Out of curiosity Gert, why would Railo be slower finding #variables.foo# than finding #foo# if variable cascading is on? Is it checking for the existence of a struct named variables before checking the actual scope or something? Judah On Thu, Dec 10, 2009 at 8:40 AM, Gert Franz gert.fr...@railo.ch wrote: Yes... that's true. If you even scope the variables from the variables scope (EXCEPT in components, since they have their own variables scope) CF is around 4 times slower than addressing a variable from there without the prefix variables. But this execution isn't very significant when your website is quite slow. It is 4 times faster not to scope variables from the variables scope, but in reality you won't notice that much improvement since accessing variables in comparison to querying a database is really a matter of order of magnitudes (So maybe variables.whatever executes in 12 nano seconds, where as whatever executes in 3 nano seconds, whereas a query will take 1ms which is 1000 nano seconds). In Railo you can enable a setting that actually forces you to scope your variables from the various scopes. So for instance if you do something like this: cfoutput#id#/cfoutput and ID is in the URL scope Railo will complain that it doesn't know the variable ID (if this setting is turned on) and throw an error. So you HAVE TO write it like this: cfoutput#url.id#/cfoutput Then Railo processes the page without error. Once you have scoped all your variables the system will be somewhat faster. Just imagine it like this: You are searching for a Peter (a variable) in a school (CF memory). You enter every classroom (scope) and check whether a pupil named Peter is sitting in it. If you find it, thats your variable. But if you know that Peter is sitting in the classroom number 55 then you go directly there and look for Peter. With the scope cascading disabled, Railo will not allow you to look for a Peter in the school without the classroom number. Hope that helps a little. Greetings from Switzerland Gert Fran ~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:329071 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: scoping and speed
According to Adobe, Yes. http://www.adobe.com/devnet/coldfusion/articles/coldfusion_performance_04.html Thanks, Eric Cobb http://www.cfgears.com Chad Gray wrote: If you don't scope your local variables does the page run slower? IE. #variables.foo# vs. #foo# ~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:329072 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: scoping and speed
Actually I think that was my bad. I had mentioned that I heard #foo# evaluates faster than #variables.foo# on Railo. Guess I heard (or remembered) incorrectly :) Sorry 'bout that. On Thu, Dec 10, 2009 at 1:11 PM, Gert Franz gert.fr...@railo.ch wrote: Judah, you got me wrong. For Railo there is no difference if searching #variables.foo# instead of #foo#. It is only a difference for Adobe CF. Here ACF checks whether there is a struct called variables in the variables scope and if not it will check the variables scope. If you only have foo it will check the variables scope instantly since there is no . in the variable addressing and hence it's faster. In Railo variables.foo is identical to foo. This is one reason why we do not support dots in variable names like ACF if you use something like this: cfset variables[susi.peter] = 5 cfoutput#susi.peter#/cfoutput --- this works in ACF but not in Railo. Railo throws an error saying that there is no key named peter in the struct susi. ACF assumes first the same and in case of an error it checks the variables scope for a variable with the key susi.peter. In Railo you have to write: cfoutput#variables[susi.peter]#/cfoutput Since we do not allow the first notation, when you have something like variables.foo Railo knows that it will check the variables scope at compile time. ACF does not! Hope that clarifies things a little. Greetings from Switzerland Gert Franz Railo Technologies Professional Open Source skype: gert.franz g...@getrailo.com +41 76 5680 231 www.getrailo.com -Ursprüngliche Nachricht- Von: Judah McAuley [mailto:ju...@wiredotter.com] Gesendet: Donnerstag, 10. Dezember 2009 20:16 An: cf-talk Betreff: Re: scoping and speed Out of curiosity Gert, why would Railo be slower finding #variables.foo# than finding #foo# if variable cascading is on? Is it checking for the existence of a struct named variables before checking the actual scope or something? Judah On Thu, Dec 10, 2009 at 8:40 AM, Gert Franz gert.fr...@railo.ch wrote: Yes... that's true. If you even scope the variables from the variables scope (EXCEPT in components, since they have their own variables scope) CF is around 4 times slower than addressing a variable from there without the prefix variables. But this execution isn't very significant when your website is quite slow. It is 4 times faster not to scope variables from the variables scope, but in reality you won't notice that much improvement since accessing variables in comparison to querying a database is really a matter of order of magnitudes (So maybe variables.whatever executes in 12 nano seconds, where as whatever executes in 3 nano seconds, whereas a query will take 1ms which is 1000 nano seconds). In Railo you can enable a setting that actually forces you to scope your variables from the various scopes. So for instance if you do something like this: cfoutput#id#/cfoutput and ID is in the URL scope Railo will complain that it doesn't know the variable ID (if this setting is turned on) and throw an error. So you HAVE TO write it like this: cfoutput#url.id#/cfoutput Then Railo processes the page without error. Once you have scoped all your variables the system will be somewhat faster. Just imagine it like this: You are searching for a Peter (a variable) in a school (CF memory). You enter every classroom (scope) and check whether a pupil named Peter is sitting in it. If you find it, thats your variable. But if you know that Peter is sitting in the classroom number 55 then you go directly there and look for Peter. With the scope cascading disabled, Railo will not allow you to look for a Peter in the school without the classroom number. Hope that helps a little. Greetings from Switzerland Gert Fran ~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:329075 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: scoping
If you don't explicitly assign a variable to a scope, then it's automatically put into the VARIABLES scope. So in your example, you could refer to your var as foo and it would be just fine. Having said that, it's a best practice to explicitly scope your variables to avoid confusion, and potential collisions. andy -Original Message- From: Chad Gray [mailto:cg...@careyweb.com] Sent: Monday, June 15, 2009 9:22 AM To: cf-talk Subject: scoping Say you defined a local variable like this on a CFM page and it returns a query object: cfset foo = application.foo.moo() Should I write out my variables like this when I out the query object? #variables.foo.goo# Or is this sufficient? #foo.goo# ~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:323503 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: scoping
#foo.goo# is acceptable. I, personally, explicitly scope every variable: cfset VARIABLES.foo = APPLICATION.foo.moo() / #VARIABLES.foo.goo# We also have an extremely high traffic, high utilization application, so explicitly scoping every var helps us keep memory in check (plus makes maintaining the code easier). Steve Cutter Blades Adobe Certified Professional Advanced Macromedia ColdFusion MX 7 Developer Co-Author of Learning Ext JS http://www.packtpub.com/learning-ext-js/book _ http://blog.cutterscrossing.com On 6/15/2009 9:22 AM, Chad Gray wrote: Say you defined a local variable like this on a CFM page and it returns a query object: cfset foo = application.foo.moo() Should I write out my variables like this when I out the query object? #variables.foo.goo# Or is this sufficient? #foo.goo# ~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:323504 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Scoping variables
I have never run into the problems directly as I never explicitly use the variables scope. However, I have seen emails on this list and others about the problems. Unfortunately, the best I can do is tell you to search the archives. Matt Liotta President CEO Montara Software, Inc. http://www.montarasoftware.com/ V: 415-577-8070 F: 415-341-8906 P: [EMAIL PROTECTED] -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 6:04 PM To: CF-Talk Subject: RE: Scoping variables However, there are currently some bugs in CFMX related to the use of explicit variables scoping. Could you provide more details, off the top of your head? I haven't run into those problems yet (probably due to my own laziness in explicitly scoping local variables, generally). Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Scoping variables
Curious question, since CFMX is compiling the source and such -- is it necessary to scope the 'variables' scope...? Seems that anything that is created that is outside the realm of form, url, session, application, server is automatically shoved into the 'variables' scope/structure. No, you don't have to explicitly reference the Variables scope, either when creating or referencing local variables. However, it's considered by many to be a good idea, since it removes any potential ambiguity about exactly what variable you're talking about. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Scoping variables
However, there are currently some bugs in CFMX related to the use of explicit variables scoping. Matt Liotta President CEO Montara Software, Inc. http://www.montarasoftware.com/ V: 415-577-8070 F: 415-341-8906 P: [EMAIL PROTECTED] -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 5:52 PM To: CF-Talk Subject: RE: Scoping variables Curious question, since CFMX is compiling the source and such -- is it necessary to scope the 'variables' scope...? Seems that anything that is created that is outside the realm of form, url, session, application, server is automatically shoved into the 'variables' scope/structure. No, you don't have to explicitly reference the Variables scope, either when creating or referencing local variables. However, it's considered by many to be a good idea, since it removes any potential ambiguity about exactly what variable you're talking about. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Scoping variables
However, there are currently some bugs in CFMX related to the use of explicit variables scoping. Could you provide more details, off the top of your head? I haven't run into those problems yet (probably due to my own laziness in explicitly scoping local variables, generally). Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Scoping variables
Such as? I'm not that up on the bug tracking front. I'm interested to know what issues exist in this area. Thanks. J. John Wilker Codito, ergo sum Web Applications Consultant, and Writer Macromedia Certified ColdFusion Developer President/Founder, Inland Empire CFUG. www.red-omega.com I asked Do you know DOS? The reply was: No, but I met Tom and Drew a few minutes ago. -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 5:51 PM To: CF-Talk Subject: RE: Scoping variables However, there are currently some bugs in CFMX related to the use of explicit variables scoping. Matt Liotta President CEO Montara Software, Inc. http://www.montarasoftware.com/ V: 415-577-8070 F: 415-341-8906 P: [EMAIL PROTECTED] -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 5:52 PM To: CF-Talk Subject: RE: Scoping variables Curious question, since CFMX is compiling the source and such -- is it necessary to scope the 'variables' scope...? Seems that anything that is created that is outside the realm of form, url, session, application, server is automatically shoved into the 'variables' scope/structure. No, you don't have to explicitly reference the Variables scope, either when creating or referencing local variables. However, it's considered by many to be a good idea, since it removes any potential ambiguity about exactly what variable you're talking about. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Scoping Variable
CF automatically will search up if you only use q. If you don't want that, then specify URL.Q, or Variables.Q, or whatever. If you _want_ it to scope up, just use q. == = Raymond Camden, Principal Spectra Compliance Engineer for Macromedia Email : [EMAIL PROTECTED] ICQ UIN : 3679482 My ally is the Force, and a powerful ally it is. - Yoda -Original Message- From: Michael Lugassy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 18, 2001 9:35 AM To: CF-Talk Subject: Scoping Variable how do I enforce CF to use only url.q and not simply q i.e - how to ask cf to search for scoping on every variable? where is it in the administrator? Thanks, Michael ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Scoping Variable
by doing exactly what you said!. Prefix your variables with the scope e.g. url.q, form.q, client.q, etc The order with which CF looks for them is: QUERY RESULT VARS LOCAL CGI FILE URL FORM COOKIE CLIENT -- Andrew Ewings Project Manager Thoughtbubble Ltd http://www.thoughtbubble.net -- United Kingdom http://www.thoughtbubble.co.uk/ Tel: +44 (0) 20 7387 8890 -- New Zealand http://www.thoughtbubble.co.nz/ Tel: +64 (0) 9 488 9131 -- The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). Any views or opinions presented are solely those of the author and do not necessarily represent those of Thoughtbubble. This information may be subject to legal, professional or other privilege and further distribution of it is strictly prohibited without our authority. If you are not the intended recipient, you are not authorised to disclose, copy, distribute, or retain this message. Please notify us on +44 (0)207 387 8890. -Original Message- From: Michael Lugassy [mailto:[EMAIL PROTECTED]] Sent: 18 July 2001 14:35 To: CF-Talk Subject: Scoping Variable how do I enforce CF to use only url.q and not simply q i.e - how to ask cf to search for scoping on every variable? where is it in the administrator? Thanks, Michael ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Scoping Variable
wasn't there a switch in cf admin that would only use SCOPE variables and WON'T allow, let say: a URL.p to be considered a FORM.p? I think I read it boost performance also? but I might be confused with something else. Thanks, Michael - Original Message - From: Andy Ewings [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Wednesday, July 18, 2001 2:45 PM Subject: RE: Scoping Variable by doing exactly what you said!. Prefix your variables with the scope e.g. url.q, form.q, client.q, etc The order with which CF looks for them is: QUERY RESULT VARS LOCAL CGI FILE URL FORM COOKIE CLIENT -- Andrew Ewings Project Manager Thoughtbubble Ltd http://www.thoughtbubble.net -- United Kingdom http://www.thoughtbubble.co.uk/ Tel: +44 (0) 20 7387 8890 -- New Zealand http://www.thoughtbubble.co.nz/ Tel: +64 (0) 9 488 9131 -- The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). Any views or opinions presented are solely those of the author and do not necessarily represent those of Thoughtbubble. This information may be subject to legal, professional or other privilege and further distribution of it is strictly prohibited without our authority. If you are not the intended recipient, you are not authorised to disclose, copy, distribute, or retain this message. Please notify us on +44 (0)207 387 8890. -Original Message- From: Michael Lugassy [mailto:[EMAIL PROTECTED]] Sent: 18 July 2001 14:35 To: CF-Talk Subject: Scoping Variable how do I enforce CF to use only url.q and not simply q i.e - how to ask cf to search for scoping on every variable? where is it in the administrator? Thanks, Michael ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Scoping Variable
wasn't there a switch in cf admin that would only use SCOPE variables and WON'T allow, let say: a URL.p to be considered a FORM.p? I don't believe so. I think I read it boost performance also? but I might be confused with something else. Yes, it is better to scope your variables, not only for performance (although I doubt it really impacts things that much), but for stability/security as well. == = Raymond Camden, Principal Spectra Compliance Engineer for Macromedia Email : [EMAIL PROTECTED] ICQ UIN : 3679482 My ally is the Force, and a powerful ally it is. - Yoda ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Scoping Variable
wasn't there a switch in cf admin that would only use SCOPE variables and WON'T allow, let say: a URL.p to be considered a FORM.p? I think I read it boost performance also? but I might be confused with something else. You're probably thinking of Enforce Strict Attribute Validation in the Administrator Philip Arnold Director Certified ColdFusion Developer ASP Multimedia Limited T: +44 (0)20 8680 1133 Websites for the real world ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ** ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Scoping
1. Can variables in the application scope be made available to custom
tags?
(I know I can set application variables in the request scope which will
make
them available to custom tags.)
Yes Application Scoped vars are available to Custom tags. The application
scope that is used is the scope of the calling template .
2. If I set variables in my application.cfm to be in the request scope,
does
this mean they are set every "request" to the web site? It seems as if my
app.cfm is no longer being cached but is instead being processed every
page
view. How can I test to see if this is true, or does anyone know FOR SURE
the behavior of the request scope?
Yes they are set for each request as request scope only lasts for the for
the length of the request , unlike application vars which are stored in
memory.
Try something like
cfif not IsDefined("Application.IsInitialised")
!---set your app vars ---
cfset Application.IsInitialised = 1
/cfif
Justin MacCarthy
--
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
