Scoping
I have several questions regarding scoping, application.cfm and custom tags. 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.) 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? Matthew Taylor Web Developer 617.868.0009 ext.216 [EMAIL PROTECTED] www.uclick.com -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
scoping
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:344619 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
scoping
Say you defined a local variable like this on a CFM page and it returns a query object: 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:323501 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Scoping variables
Curious question, since CFMX is compiling the source and such -- it 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. ~Todd Todd Rafferty ([EMAIL PROTECTED]) http://www.web-rat.com/ Team Macromedia Volunteer for ColdFusion http://www.macromedia.com/support/forums/team_macromedia/ Moderator @ FlashCFM.com - http://www.flashCFM.com/ Back-end Moderator @ Ultrashock.com - http://www.ultrashock.com/ __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.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
> > 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 Justin MacCarthy -- Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
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
Local scope is only implied when using cf9 On May 18, 2011, at 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: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 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 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: instead I do: But I always would do: #Variables.strBlah# or 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 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 > 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 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 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 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 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 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" 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 > 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
Curiously, I do it the exact opposite way: #myVariable# However, I should probably scope both. Dominic On 18 May 2011 19:26, Aaron Rouse wrote: > > This is my outlook although I do not do something like: > > > > instead I do: > > > > But I always would do: > > #Variables.strBlah# > > or > > > > 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 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 >> 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 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" 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 > -scoping<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: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: > > > > #myVariable# > > However, I should probably scope both. > > Dominic > > On 18 May 2011 19:26, Aaron Rouse wrote: >> This is my outlook although I do not do something like: >> >> >> >> instead I do: >> >> >> >> But I always would do: >> >> #Variables.strBlah# >> >> or >> >> >> >> 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 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 >>> 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 #Variables.myVariable# 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 and 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: > > > > #myVariable# > > However, I should probably scope both. > > Dominic > > On 18 May 2011 19:26, Aaron Rouse wrote: > > > > This is my outlook although I do not do something like: > > > > > > > > instead I do: > > > > > > > > But I always would do: > > > > #Variables.strBlah# > > > > or > > > > > > > > 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: form.test = #form.test# test = #test# 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: (output = 'test') Oivay! On 19 May 2011 13:47, Eric Cobb 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
Re: scoping
On Wed, May 18, 2011 at 12:51 PM, 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? 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: > > > > #myVariable# > > However, I should probably scope both. > > Dominic > > On 18 May 2011 19:26, Aaron Rouse wrote: >> This is my outlook although I do not do something like: >> >> >> >> instead I do: >> >> >> >> But I always would do: >> >> #Variables.strBlah# >> >> or >> >> >> >> 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 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 >>> 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: >> >> >> >> #myVariable# >> >> However, I should probably scope both. >> >> Dominic >> >> On 18 May 2011 19:26, Aaron Rouse wrote: >>> This is my outlook although I do not do something like: >>> >>> >>> >>> instead I do: >>> >>> >>> >>> But I always would do: >>> >>> #Variables.strBlah# >>> >>> or >>> >>> >>> >>> 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 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 >>>>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: 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 Ses
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 s
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 t
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: vs 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: #foo# vs #Variables.foo# 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
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 wrote: > > 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: 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 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 wrote: > > On Fri, May 20, 2011 at 4:54 AM, Aaron Rouse 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
>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 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
>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: No scope: c=#c#, time=#GetTickCount()-stTime# Scope: c=#c#, time=#GetTickCount()-stTime# 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: Function no scope: #GetTickCount()-stTime# Function scope: #GetTickCount()-stTime# c=#c# c=#c# 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
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: 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: #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: > > > > 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
AW: scoping
Steve, just a quick info here. If you have every variable in the variables scope prefixed with "variables." it is actually slower (factor 2 at least) than if you address it without the "variables." notation. This is valid for Adobe's CFML implementation. In Railo it's indifferent. Whereas inside CFC's the "variables." notation is faster than writing it without the "variables.". My personal recommendation is: Scope everything except the variables scope. And for readability reasons scope queries as well! So do it like this: #susi.name# Greetings from Switzerland Gert Franz Railo Technologies Professional Open Source skype: gert.franz g...@getrailo.com www.getrailo.ch -Ursprüngliche Nachricht- Von: Cutter (CFRelated) [mailto:cold.fus...@cutterscrossing.com] Gesendet: Montag, 15. Juni 2009 16:28 An: cf-talk Betreff: Re: scoping #foo.goo# is acceptable. I, personally, explicitly scope every variable: #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: > > > > 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:323510 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
cftry/catch scoping
If I have a cftry block which contains calls to custom tags, what happens if there is an error in one of the custom tags? I would expect that the exception would be thrown out and caught by the catch block of the cftry, but that doesn't seem to be the case. I'm still getting untrapped errors out of the custom tags. Can anyone confirm this, or am I doing something wrong? CF version is 5.0 Professional. __ 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
> 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 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 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
Singleton & var scoping
I know that var scoping is paramount with CFC development, however, I do have a question in regards to var scoping when the CFC is not going to be a singleton and the impact that might have. Please consider the following simplified example: In this example doSomething() creates a new object and then calls doSomethingElse() in the new non-singleton object. Inside doSomethingElse() there could be non var scoped variables. While I understand this is not good practice nor recommended, am I also correct in assuming that you could run into issues b/c the variables are not private to the function call? Or because the CFC always will be created with each invocation of doSomething() will it be ok. Thanks. ~| 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:341971 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 Chabot 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: 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 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.
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: <-- using the Variables scope <-- using the Variables scope <-- 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: 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: 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: 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 ... I do not do #Variables.qryGetData.ColumnName# instead I do #qryGetData.ColumnName# 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
CFC Scoping Error
I'm developing an application using CFMX developers edition...my application was working fine...and boom the following error crept up. I have download and installed the CFMX 6.1 Updater, but this does not solve the problem any ideas? LINE OF CODE: ERROR MESSAGE: java.lang.NullPointerException at coldfusion.runtime.TemplateClassLoader.newInstance(TemplateClassLoader.java:327) at coldfusion.runtime.TemplateProxyFactory.resolveName(TemplateProxyFactory.java:98) at coldfusion.runtime.TemplateProxyFactory.resolveName(TemplateProxyFactory.java:212) at coldfusion.runtime.TemplateProxyFactory.resolveName(TemplateProxyFactory.java:564) at coldfusion.runtime.CFPage.CreateObject(CFPage.java:5047) at coldfusion.tagext.lang.ObjectTag.doStartTag(ObjectTag.java:193) at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:1876) at cfApplication2ecfm878193445.runPage(C:\CFusionMX\wwwroot\TakeoutPoint\Application.cfm:131) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:147) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:357) at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:62) at coldfusion.filter.CfincludeFilter.include(CfincludeFilter.java:30) at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:93) at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:47) at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:35) at coldfusion.filter.PathFilter.invoke(PathFilter.java:80) at coldfusion.filter.LicenseFilter.invoke(LicenseFilter.java:24) at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28) at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:43) at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22) at coldfusion.xml.rpc.CFCServlet.invoke(CFCServlet.java:62) at coldfusion.xml.rpc.CFCServlet.doGet(CFCServlet.java:113) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:339) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91) at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:249) at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:527) at jrun.servlet.http.WebService.invokeRunnable(WebService.java:168) at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:348) at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:451) at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:294) at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66) ~| Purchase from House of Fusion, a Macromedia Authorized Affiliate and support the CF community. http://www.houseoffusion.com/banners/view.cfm?bannerid=37 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:181807 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
scoping and speed
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:329039 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Weird scoping issue
Hey all would you please take a look at the following code:
isdefined member_id = #isdefined("url.member_id")#
isdefined member_id = #isdefined("url.member_id")#
isdefined member_id = #isdefined("url.member_id")#
(I did not write it, please exclude the errant use of cfoutput and cfloop)
Here's what's happening. getMemberDetail() is a method that returns
one record from the DB.
member_id is passed in via URL param.
For some reason, the second isDefined call returns NO, while the first
and third properly returns YES.
Anyone ever seen this before?
We're running 64 bit CF8.0.1 on Windows Server 2008 x64
The CFC method does not make any references to the url scope. The
behavior is the same if I use cfloop instead of cfoutput over the
query.
--
Rick Root
New Brian Vander Ark Album, songs in the music player and cool behind
the scenes video at www.myspace.com/brianvanderark
~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to
date
Get the Free Trial
http://ad.doubleclick.net/clk;207172674;29440083;f
Archive:
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:319989
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: cftry/catch scoping
I think it works like this (but I'm not positive): custom tags operate in their own memory space - they do not share memory space with the calling procedure. Therefore if you want the calling template to capture errors you'll need to somehow notify that template. I believe the calling template will capture errors thrown in CFINCLUDEs (since they operate in the same memory space), so you might try that instead. +---+ Bryan Love Macromedia Certified Professional Internet Application Developer Database Analyst Telecommunication Systems [EMAIL PROTECTED] +---+ "...'If there must be trouble, let it be in my day, that my child may have peace'..." - Thomas Paine, The American Crisis -Original Message- From: Rob Baxter [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 9:48 AM To: CF-Talk Subject: cftry/catch scoping If I have a cftry block which contains calls to custom tags, what happens if there is an error in one of the custom tags? I would expect that the exception would be thrown out and caught by the catch block of the cftry, but that doesn't seem to be the case. I'm still getting untrapped errors out of the custom tags. Can anyone confirm this, or am I doing something wrong? CF version is 5.0 Professional. __ 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: cftry/catch scoping
> If I have a cftry block which contains calls to custom > tags, what happens if there is an error in one of the > custom tags? I would expect that the exception would be > thrown out and caught by the catch block of the cftry, > but that doesn't seem to be the case. I'm still getting > untrapped errors out of the custom tags. Can anyone > confirm this, or am I doing something wrong? CF version > is 5.0 Professional. You can, in fact, catch exceptions thrown by a custom tag within your calling page. Not all errors are exceptions, though - if you have a misspelled CFML tag in your custom tag, that will create a parsing error which occurs before runtime, rather than a runtime exception. In addition, the CFTRY block within your calling page has to contain CFCATCH blocks with the appropriate types: no type specified (which is equivalent to TYPE="ANY", more or less), TYPE="Application", or some custom type that's thrown by the custom tag using CFTHROW. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ Get the mailserver that powers this list at http://www.coolfusion.com 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
Frames and variable scoping
I have a frameset that is called through a form post. How should I refer to those posted variables within a frame inside that frameset? Do I pass them as url variables in the template call of the frame tag? Lon Lentz Applications Developer and CyberEntomolgist http://ProofitOnline.Com - Free 15 Day Trial ~~ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.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: Singleton & var scoping
> I know that var scoping is paramount with CFC development, however, I do have > a question in regards to var scoping when the CFC is not going > to be a singleton and the impact that might have. > > Please consider the following simplified example: > > > > > /> > > > > > > > > > > > > In this example doSomething() creates a new object and then calls > doSomethingElse() in the new non-singleton object. Inside > doSomethingElse() there could be non var scoped variables. While I > understand this is not good practice nor recommended, am I also correct in > assuming that you could run into issues b/c the variables are not private to > the function call? Or because the CFC always will be created with > each invocation of doSomething() will it be ok. It will be ok, as you're creating a new separate instance of your non-singleton CFC for each call to doSomething. 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, onlin ~| 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:341992 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: CFC Scoping Error
try use dot notation for the component where dirname is at the root of a CF path. Doug On Tue, 19 Oct 2004 00:26:19 -0400, Lugene Johnson <[EMAIL PROTECTED]> wrote: > I'm developing an application using CFMX developers edition...my application was > working fine...and boom the following error crept up. I have download and installed > the CFMX 6.1 Updater, but this does not solve the problem any ideas? > > LINE OF CODE: > > > > ERROR MESSAGE: > java.lang.NullPointerException >at > coldfusion.runtime.TemplateClassLoader.newInstance(TemplateClassLoader.java:327) >at > coldfusion.runtime.TemplateProxyFactory.resolveName(TemplateProxyFactory.java:98) >at > coldfusion.runtime.TemplateProxyFactory.resolveName(TemplateProxyFactory.java:212) >at > coldfusion.runtime.TemplateProxyFactory.resolveName(TemplateProxyFactory.java:564) >at coldfusion.runtime.CFPage.CreateObject(CFPage.java:5047) >at coldfusion.tagext.lang.ObjectTag.doStartTag(ObjectTag.java:193) >at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:1876) >at > cfApplication2ecfm878193445.runPage(C:\CFusionMX\wwwroot\TakeoutPoint\Application.cfm:131) >at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:147) >at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:357) >at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:62) >at coldfusion.filter.CfincludeFilter.include(CfincludeFilter.java:30) >at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:93) >at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:47) >at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:35) >at coldfusion.filter.PathFilter.invoke(PathFilter.java:80) >at coldfusion.filter.LicenseFilter.invoke(LicenseFilter.java:24) >at > coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28) >at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:43) >at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22) >at coldfusion.xml.rpc.CFCServlet.invoke(CFCServlet.java:62) >at coldfusion.xml.rpc.CFCServlet.doGet(CFCServlet.java:113) >at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) >at > org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:339) >at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91) >at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) >at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:249) >at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:527) >at jrun.servlet.http.WebService.invokeRunnable(WebService.java:168) >at > jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:348) >at > jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:451) >at > jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:294) >at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66) > > ~| Purchase from House of Fusion, a Macromedia Authorized Affiliate and support the CF community. http://www.houseoffusion.com/banners/view.cfm?bannerid=35 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:181810 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
OT: JavaScript Scoping Gurus?
I'm building an HTTP request pooler in JS. In essence the pool creates
several HTTP objects and allows the programmer to add requests to the queue.
The queue is then examined at an interval and queued requests are passed to
free objects for calls.
Anyway - all that seems to work pretty well - except setting up the
interval.
Let's assume this simplified Object:
// Create the Pool
function HTTPRequestPool(ObInstanceCount, IntervalCount) {
// Create a Queue for Requests
this.RequestQueue = new Array();
App.RequestPoolTimer = window.setInterval("this.doRequest();", 500);
};
HTTPRequestPool.prototype.addRequest = function addRequest( Method, URL,
Parameters, Handler) { };
HTTPRequestPool.prototype.doRequest = function doRequest() { };
We would instantiate this like this (someplace on the page):
RequestPool = new HTTPRequestPool(5, 500);
The problem is the interval - in this case the doRequest() method, when
called from the interval, loses the connection to the parent object. When
called "this" refers to the top-level window (as it would when a top-level
function is called) NOT to the parent object (as it would when a method is
called).
However if I remove the interval from the object and instantiate things like
this (setting the interval outside of the object):
RequestPool = new HTTPRequestPool(5, 500);
App.RequestPoolTimer = window.setInterval("RequestPool.doRequest();", 500);
Everything works fine - the interval never loses its reference.
This is a workaround, but I'd much rather have the interval contained in the
object itself.
Thanks in advance for any ideas.
Jim Davis
~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:235861
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
RE: JavaScript Scoping Gurus?
Jim,
What I've always done to counter this problem is to create an API
class--which I use to monitor instances of each class and hold "global"
functionality. For example:
function _HRPApi(){
this.instance = [];
}
_HRPApi.prototype.register = function (obj){
var iInstance = this.instance.length;
this.instance[iInstance] = obj;
return iInstance;
}
// create the global class
HTTPRequestPoolApi = new _HRPApi();
Now in your actual class, you can do something like:
function HTTPRequestPool(){
this.instance = HTTPRequestPoolApi.register(this);
this.interval = 500; // number of ms to wait before setTimeout
}
Now, anytime you need to reference the current instance of the class from a
global function (such as inside the setTimeout) you've got a copy stored in
a global variable (HTTPRequestPoolApi) you can access it with something like
the following code:
setTimeout(
"HTTPRequestPoolApi.instance[" + this.instance + "].method();",
this.interval
);
Hope this helps!
-Dan
>-Original Message-
>From: Jim Davis [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 21, 2006 10:37 AM
>To: CF-Talk
>Subject: OT: JavaScript Scoping Gurus?
>
>I'm building an HTTP request pooler in JS. In essence the pool creates
>several HTTP objects and allows the programmer to add requests to the
>queue.
>The queue is then examined at an interval and queued requests are passed to
>free objects for calls.
>
>Anyway - all that seems to work pretty well - except setting up the
>interval.
>
>Let's assume this simplified Object:
>
> // Create the Pool
>function HTTPRequestPool(ObInstanceCount, IntervalCount) {
>
> // Create a Queue for Requests
> this.RequestQueue = new Array();
>
> App.RequestPoolTimer = window.setInterval("this.doRequest();", 500);
>
>};
>
>HTTPRequestPool.prototype.addRequest = function addRequest( Method, URL,
>Parameters, Handler) { };
>
>HTTPRequestPool.prototype.doRequest = function doRequest() { };
>
>
>We would instantiate this like this (someplace on the page):
>
>RequestPool = new HTTPRequestPool(5, 500);
>
>The problem is the interval - in this case the doRequest() method, when
>called from the interval, loses the connection to the parent object. When
>called "this" refers to the top-level window (as it would when a top-level
>function is called) NOT to the parent object (as it would when a method is
>called).
>
>However if I remove the interval from the object and instantiate things
>like
>this (setting the interval outside of the object):
>
>RequestPool = new HTTPRequestPool(5, 500);
>App.RequestPoolTimer = window.setInterval("RequestPool.doRequest();", 500);
>
>Everything works fine - the interval never loses its reference.
>
>This is a workaround, but I'd much rather have the interval contained in
>the
>object itself.
>
>Thanks in advance for any ideas.
>
>Jim Davis
>
>
>
~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:235865
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
RE: JavaScript Scoping Gurus?
> -Original Message-
> From: Dan G. Switzer, II [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 21, 2006 11:10 AM
> To: CF-Talk
> Subject: RE: JavaScript Scoping Gurus?
>
> Jim,
>
> What I've always done to counter this problem is to create an API
> class--which I use to monitor instances of each class and hold "global"
> functionality. For example:
Thanks... but I really hate "tainting" the global scope if I can at all help
it.
I think I've found an answer however. The problem is that "setInterval()"
runs in context of the window object and that the code sent to it is treated
as a string (it's evaluated every time it's run) so "this" can't be passed.
Instead you can force lexical scoping to be honored by using a proxy
function in the scope of the object - the function reference maintains its
scope since it's "pinned" to the context in which it was created.
Here's how I ended up doing it:
// Create the Pool
function HTTPRequestPool(ObInstanceCount, IntervalCount) {
... lots of other code ...
// Set a proxy function to maintain scoping when called in
the context of Window
var ThisPool = this;
var IntervalProxy = function() { ThisPool.doRequest() };
// Start the Interval
window.setInterval(IntervalProxy, IntervalCount);
};
This works a treat.
Note that it's pretty "fragile" in the sense that all those parts are
needed. Doing the following doesn't work:
var IntervalProxy = function() { this.doRequest() };
window.setInterval(IntervalProxy, IntervalCount);
This doesn't work either (because you must pass a reference to the function
rather than the function call):
var ThisPool = this;
var IntervalProxy = function() { ThisPool.doRequest() };
window.setInterval(IntervalProxy(), IntervalCount);
It's like you have to "pin" and reinforce the reference to the object at
every step.
Considering that I don't feel so bad that it took a while for me to get it.
;^)
Jim Davis
~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:235870
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
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 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
AW: scoping and speed
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: #id# 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: #url.id# 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 Franz Railo Technologies Professional Open Source skype: gert.franz g...@getrailo.com +41 76 5680 231 www.getrailo.com -Ursprüngliche Nachricht- Von: Charlie Griefer [mailto:charlie.grie...@gmail.com] Gesendet: Donnerstag, 10. Dezember 2009 16:59 An: cf-talk Betreff: 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 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:329053 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 Date: Thu, December 10, 2009 9:59 am To: cf-talk "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 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: > #id# > 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: > #url.id# > 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
AW: scoping and speed
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: #susi.peter# <--- 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: #variables["susi.peter"]# 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 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: > #id# > 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: > #url.id# > 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:329073 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 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: > > #susi.peter# <--- 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: > #variables["susi.peter"]# > 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 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: > > #id# > > 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: > > #url.id# > > 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: Weird scoping issue
shoot never mind, the member detail record contains a field named "url"
On Mon, Mar 2, 2009 at 8:58 AM, Rick Root wrote:
> Hey all would you please take a look at the following code:
>
>
> isdefined member_id = #isdefined("url.member_id")#
> includeTextFields=true)>
>
> isdefined member_id = #isdefined("url.member_id")#
>
> isdefined member_id = #isdefined("url.member_id")#
>
>
> (I did not write it, please exclude the errant use of cfoutput and cfloop)
>
> Here's what's happening. getMemberDetail() is a method that returns
> one record from the DB.
>
> member_id is passed in via URL param.
>
> For some reason, the second isDefined call returns NO, while the first
> and third properly returns YES.
>
> Anyone ever seen this before?
>
> We're running 64 bit CF8.0.1 on Windows Server 2008 x64
>
> The CFC method does not make any references to the url scope. The
> behavior is the same if I use cfloop instead of cfoutput over the
> query.
>
> --
> Rick Root
> New Brian Vander Ark Album, songs in the music player and cool behind
> the scenes video at www.myspace.com/brianvanderark
>
--
Rick Root
New Brian Vander Ark Album, songs in the music player and cool behind
the scenes video at www.myspace.com/brianvan
~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to
date
Get the Free Trial
http://ad.doubleclick.net/clk;207172674;29440083;f
Archive:
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:319990
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Weird scoping issue
What happens if you switch it to StructKeyExists( url , 'member_id' ) ? ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;207172674;29440083;f Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:319992 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Weird scoping issue
On Mon, Mar 2, 2009 at 9:12 AM, Peter Boughton wrote: > > What happens if you switch it to StructKeyExists( url , 'member_id' ) ? See my previous message. The answer to your question is: it errors because "url" is a string in the returned query. Another good reason to use structkeyexists instead of isdefined! =) Actually that's how I figured it out, while I was experimenting, I tried STructKeyExists... Rick -- Rick Root New Brian Vander Ark Album, songs in the music player and cool behind the scenes video at www.myspace.com/brianvanderark ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;207172674;29440083;f Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:319998 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Variable Scoping in CF8, CF9
I know that correctly scoping variables in ColdFusion is important to prevent unexpected results if a variable is "accidentally" reused elsewhere in a CFC. But, if I remember correctly, in CFMX there were some pretty nasty memory leaks that could occur if variables weren't scoped correctly. Does that apply to newer (8,9) versions of ColdFusion? - Matthew ~| 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:340255 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Frames and variable scoping
Check out this: http://www.cfugorama.com/cfugorama/DevCon.cfm Download the Ninja Javascript Presentation. Steve went through something like this although using a hidden frame but it's still passing variables through a frame. Kelly -Original Message- From: Lon Lentz [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 5:16 PM To: CF-Talk Subject: Frames and variable scoping I have a frameset that is called through a form post. How should I refer to those posted variables within a frame inside that frameset? Do I pass them as url variables in the template call of the frame tag? Lon Lentz Applications Developer and CyberEntomolgist http://ProofitOnline.Com - Free 15 Day Trial ~~ Get the mailserver that powers this list at http://www.coolfusion.com 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: Frames and variable scoping
Keep in mind that variables are processed server side while the frameset tags are processed client side. That means that ONLY the page you call with the form action can see the form variables - in this case that page will likely have the FRAMESET tags and nothing else. Once that page is served up the browser initiates requests for the frame sources - by this time your form variables are gone. Your only option here is to generate the frame tags on the fly using CF and put the form variables in the url string for the SRC attribute. This way when the browser makes the request for the frame source your variables will be passed in again through the url scope. You could also store the variables in a persistant scope, but it's probably not the best idea. If you do decide to do this there is one very easy way to do it: (this works because form is actually a struct pointer which is getting copied into the session.theForm variable) then you can access the variables later like this #session.theForm.fieldName# Bryan Love Macromedia Certified Professional Internet Application Developer / Database Analyst Telecommunication Systems Inc. [EMAIL PROTECTED] "What father would hesitate to say 'if there must be trouble let it be in my day, that my child may have peace'?" - Thomas Paine, An American Crisis -Original Message- From: Lon Lentz [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 2:16 PM To: CF-Talk Subject: Frames and variable scoping I have a frameset that is called through a form post. How should I refer to those posted variables within a frame inside that frameset? Do I pass them as url variables in the template call of the frame tag? Lon Lentz Applications Developer and CyberEntomolgist http://ProofitOnline.Com - Free 15 Day Trial ~~ Get the mailserver that powers this list at http://www.coolfusion.com 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: Frames and variable scoping
Thanks for the help. I am coming into an application that is already deployed. I'm here to fix bugs and add functionality. I am in the process of converting a lot of stuff to a few session scoped structures. The scoping going on in the frameset and frames is a little funky. My first goal is to get all of the variables passed and scoped properly. And if I had thought about how the thing was working, I would have been able to answer my question. Doh! The form thing is very slick, though. Thanks again! -Original Message- From: Bryan Love [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 8:43 PM To: CF-Talk Subject: RE: Frames and variable scoping Keep in mind that variables are processed server side while the frameset tags are processed client side. That means that ONLY the page you call with the form action can see the form variables - in this case that page will likely have the FRAMESET tags and nothing else. Once that page is served up the browser initiates requests for the frame sources - by this time your form variables are gone. Your only option here is to generate the frame tags on the fly using CF and put the form variables in the url string for the SRC attribute. This way when the browser makes the request for the frame source your variables will be passed in again through the url scope. You could also store the variables in a persistant scope, but it's probably not the best idea. If you do decide to do this there is one very easy way to do it: (this works because form is actually a struct pointer which is getting copied into the session.theForm variable) then you can access the variables later like this #session.theForm.fieldName# ~~ Get the mailserver that powers this list at http://www.coolfusion.com 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: Frames and variable scoping
Hi Kelly, Went and grabbed it. Very interesting and helpful reading. Thanks. -Original Message- From: Kelly Matthews [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 5:25 PM To: CF-Talk Subject: RE: Frames and variable scoping Check out this: http://www.cfugorama.com/cfugorama/DevCon.cfm Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists ~~ 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: Frames and variable scoping
Great! It was a great Session! :) Kelly www.webdiva.org -Original Message- From: Lon Lentz [mailto:[EMAIL PROTECTED]] Sent: Friday, November 02, 2001 9:41 AM To: CF-Talk Subject: RE: Frames and variable scoping Hi Kelly, Went and grabbed it. Very interesting and helpful reading. Thanks. -Original Message- From: Kelly Matthews [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 5:25 PM To: CF-Talk Subject: RE: Frames and variable scoping Check out this: http://www.cfugorama.com/cfugorama/DevCon.cfm Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists ~~ 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
More local variables scoping weirdness
So I happened to loop over a recordset in a function today and one of the
column names had the same name as an argument to the function. I thought
nothing of it, and assumed that inside my CFLOOP tag, the column's value in
the current record would have the highest priority in the scope search
queue. But that's NOT the case.
Local variables have a higher priority that columns when looping a
recordset. Thus, if you want to reference a recordset column within a
function that has either an argument or a local variable with the same name,
you have to do it longhand: #recordsetname.columnname[currentrow]#, rather
that the usual #columnname#
Anyone have any clever insights about this, and/or know if it is/should be a
bug? I think it should, but we all know my opinions on scoping are
"interesting".
To prove to myself I wasn't crazy, I wrote a simple test case and included
it below. While it will happen rarely (this is the first time it's happened
to me), it seems counterintuitive that the local variables scope would be
searched before the recordset, since the recordset loop is a narrower scope
than the local variables scope. Both CFC methods loop the recordset and
create a list of the 'id' field's values for the records. The output
should, IMHO, be "1,2,3" for all three, but it is in fact "42,42,42",
"37,37,37", and "1,2,3".
test.cfm:
-
#createObject("component", "test").testArg(q, 42)#
#createObject("component", "test").testLocal(q)#
#createObject("component", "test").testFullScope(q)#
test.cfc:
-
---
Barney Boisvert, Senior Development Engineer
AudienceCentral
[EMAIL PROTECTED]
voice : 360.756.8080 x32
fax : 360.647.5351
www.audiencecentral.com
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
RE: AW: scoping and speed
Thanks for that info about Railo, Gert. That setting is exactly what I wished I had in Adobe CF the other day. :) ~Brad Original Message Subject: AW: scoping and speed From: "Gert Franz" Date: Thu, December 10, 2009 10:40 am To: cf-talk In Railo you can enable a setting that actually forces you to scope your variables from the various scopes. ~| 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:329062 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Variable Scoping in CF8, CF9
On Thu, Dec 23, 2010 at 10:16 AM, Matthew Reinbold wrote: > > I know that correctly scoping variables in ColdFusion is important to prevent > unexpected results if a variable is "accidentally" reused elsewhere in a CFC. > But, if I remember correctly, in CFMX there were some pretty nasty memory > leaks that could occur if variables weren't scoped correctly. > > Does that apply to newer (8,9) versions of ColdFusion? Yup. All function-local variables in a CFC should be var scoped. CF 9 did introduce the "local" scope inside of CFC methods, so doing this: is functionally equivalent to doing: So while there are now 2 ways to declare a variable as local to a given function (assuming you're on CF 9), the requirement still remains that you do need to scope these variables properly in order to avoid leakage. -- Charlie Griefer http://charlie.griefer.com/ I have failed as much as I have succeeded. But I love my life. I love my wife. And I wish you my kind of success. ~| 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:340256 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Variable Scoping in CF8, CF9
On Thu, Dec 23, 2010 at 9:16 AM, Matthew Reinbold wrote: > I know that correctly scoping variables in ColdFusion is important to prevent > unexpected results if a variable is "accidentally" reused elsewhere in a CFC. > But, if I remember correctly, in CFMX there were some pretty nasty memory > leaks that could occur if variables weren't scoped correctly. Hmm, it wasn't related to memory leaks so much as thread safety - which applies to all versions of all CFML engines when you're using CFCs stored in scopes that are shared between multiple requests and it's much the same problem you have sharing data between requests anyway (it's just easier to trip over with the implicit, shared, VARIABLES scope in CFCs). -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~| 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:340258 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: More local variables scoping weirdness
AS far as I know, local variables in a function have always taken
precedent over any other scope (since they were introduced in CF5).
Because they have no prefix, this MUST be so. Otherwise you couldn't
access them in a loop over a query. Best practices is to always scope
your vars. You will never run into trouble!
For queries, you don't have to do it longhand if you are in a
query=""> or . Just write #queryname.columnname#.
This has always worked. It is just if you want to use array notation
that you need the currentrow:
#queryname[col][currentRow]#
And I think that for most developers, the output of your test is just as
it should be. I think you should never rely on the order of evaluation
for unscoped vars. ALWAYS scope or you will run into trouble sometime.
Pascal Peters
Certified ColdFusion MX Advanced Developer
Macromedia Certified Instructor
LR Technologies
Av. E. De Mot, 19
1000 BRUSSELS, BELGIUM
Tel: +32 2 639 68 70
Fax: +32 2 639 68 99
Email: [EMAIL PROTECTED]
Web: www.lrt.be
> -Original Message-
> From: Barney Boisvert [mailto:[EMAIL PROTECTED]
> Sent: donderdag 1 april 2004 23:50
> To: CF-Talk
> Subject: More local variables scoping weirdness
>
> So I happened to loop over a recordset in a function today
> and one of the column names had the same name as an argument
> to the function. I thought nothing of it, and assumed that
> inside my CFLOOP tag, the column's value in the current
> record would have the highest priority in the scope search
> queue. But that's NOT the case.
>
> Local variables have a higher priority that columns when
> looping a recordset. Thus, if you want to reference a
> recordset column within a function that has either an
> argument or a local variable with the same name, you have to
> do it longhand: #recordsetname.columnname[currentrow]#,
> rather that the usual #columnname#
>
> Anyone have any clever insights about this, and/or know if it
> is/should be a bug? I think it should, but we all know my
> opinions on scoping are "interesting".
>
> To prove to myself I wasn't crazy, I wrote a simple test case
> and included it below. While it will happen rarely (this is
> the first time it's happened to me), it seems
> counterintuitive that the local variables scope would be
> searched before the recordset, since the recordset loop is a
> narrower scope than the local variables scope. Both CFC
> methods loop the recordset and create a list of the 'id'
> field's values for the records. The output should, IMHO, be
> "1,2,3" for all three, but it is in fact "42,42,42",
> "37,37,37", and "1,2,3".
>
> test.cfm:
> -
>
>
>
>
> #createObject("component", "test").testArg(q,
> 42)# #createObject("component",
> "test").testLocal(q)# #createObject("component",
> "test").testFullScope(q)#
>
> test.cfc:
> -
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---
> Barney Boisvert, Senior Development Engineer AudienceCentral
> [EMAIL PROTECTED] voice : 360.756.8080 x32
> fax : 360.647.5351
>
> www.audiencecentral.com
>
>
>
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
About Scoping mostly url and form
At the risk of looking not too bright I have a question maybe I can get help, or someone can put me in my place So about scope. when I started coding CF (about 7 years ago) I really didn't know about scope at all, then I started using cgi session application client query struct form url and request scopes. But then I had a massive problems and had to change lots of code especialy when I had forms and urls passing variables to the same page to do the same thing. (mostly I had to write code to dump them all into request scope but I never put together a script to do it, which right now I'm sure I'll find, working with php fusebox form and url vars were dumped into an attributes array easily and I can probably base it on that) One day I just quit on the whole thing and ever since I realy haven't as many problems. What do you folks do when you want a variable that can be passed over form or url? [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
var scoping cfscript in a CFC
When putting cfscript in a CFC function do you need to use on variables created in the cfscript? Thanks, Chad ~| 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:330306 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
