Yet again, thanks guys.
I've opted for creating a Local struct in each function (as suggested by Jim) and all is going well. However, I've reached a part of my code that I'm not sure how to handle.
It basically loops through a query and creates a struct for each row and returns it as an array. It's made more complicated by some xml / xpath processing going on but I've included a simplified version below.
var Local.NodeArray = ArrayNew(1);
for(Local.index = 1; Local.index lte Arguments.NodeQuery.RecordCount; Local.index = Local.index + 1)
{
Local.Node = StructNew();
Local.Node.Value1 = Arguments.NodeQuery.Value1;
Local.Node.Value2 = Arguments.NodeQuery.Value2;
...
ArrayAppend(Local.NodeArray, Local.Node);
}
My question is this. In each iteration I create a temporary struct (Local.Node) which is then appended to an array. Do I need use my Local pseudo-scope for this struct in the same way as for other variables.
My initial thoughts are yes but I've been off-base on this one already so really wanted to check I was doing the right thing.
Cheers, Pete (aka lad4bear)
----Original Message Follows----
From: "Jim Davis" <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: <[email protected]>
Subject: RE: [CFCDev] CFC's and the var scope
Date: Mon, 30 May 2005 00:50:44 -0400
I say this a lot so some of you may have head it before. ;^)
The var/function local/unnamed scope is a pain because it's the exception in
CF - since it's unnamed it's the only scope that can't be treated like a
struct. Also since it's unnamed you can't scope references to it like you
do with all your other scopes (right, you do scope your variable
references?)
To solve these problems I've gotten in the habit of creating a "local"
pseudo scope for functions. I describe this in some detail here:
http://www.depressedpress.com/DepressedPress/Content/Development/ColdFusion/
DPLibraries/Articles/Tutorial_DPCFCs/Optional.cfm
(As an aside - all the material there should be considered "beta" - I'm
trying to flesh it all out, but I've uploaded what I have so far, unedited.)
The short version is to create a new var-scoped struct at the beginning of
every function like so:
<cffunction name="init" ...>
<!--- Set Local Scope --->
<cfset var local = StructNew() />
</cffunction>
You can then set any vars you like as keys to struct - treat it essentially
like you would any other named scope (session, form, etc). You can do this,
for example
<cfset local.Min = 1 />
<cfset local.Max = 10 />
<cfloop from="#local.Min#" to="#local.Max#" index="local.Cnt">
<cfquery name="local.MyQuery" .>
</cfquery>
</cfloop>
Note that we didn't have to declare variables at the top of the function
(although you can if you like) and we maintained thread safety.
The "local" scope can be used like any other CF scope: you can CFDUMP it,
you can iterate over it, you can access it as a struct (which is all it is
in the first place).
You do have to get in the habit of using it - but it's pretty easy. It's no
harder to do that scoping any other variables.
As I said - I say this a lot, but it's just saved me so much time and
heartache. I find it a very elegant solution to the issue and am, perhaps,
inordinately proud of it. ;^)
Jim Davis
_____
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Bill Rawlinson
Sent: Sunday, May 29, 2005 10:53 PM
To: [email protected]
Subject: Re: [CFCDev] CFC's and the var scope
Your correct Barry as far as I know all of those variables are at risk too.
and Pete - the one that might get you the most is make sure you var your
query names before you use them too:
<cfset var myQuery = "" />
<cfquery name="myQuery" datasource="xyz">
...
</cfquery>
<cfreturn myQuery />
Bill
On 5/29/05, Barry Beattie <[EMAIL PROTECTED]> wrote:
just checking my memory...
this isn't just confined to cfhttp, yes? variables created from cffile as
well (and cfsavecontent variable="etc..." and...and...)
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]
> Behalf Of Mark Mandel
> Sent: Monday, 30 May 2005 11:26 AM
> To: [email protected]
> Subject: Re: [CFCDev] CFC's and the var scope
>
>
> Oh yeah...
>
> If CFC method variables aren't var'd they are in the scope of the
> instance of the CFC itself, and can cause the CFC to be non-thread
> safe!
>
> So var your method scope variables!
>
> Mark
>
> On 5/30/05, Peter H <[EMAIL PROTECTED]> wrote:
> >
> > Hi guys,
> >
> > I bumped into the following article online relating to use
> of cfhttp and
> > components.
> >
> >
http://weblogs.macromedia.com/cantrell/archives/2005/04/dont_forget_to.cfm
>
> It basically states that you when using cfhttp in a componet you should
use
> <cfset var cfhttp.fileContent = 0/> to avoid concurreny issues.
>
> My question is this. Is cfhttp a special case? Or should I be var-ing all
> method variables. (I really hope not or I have a lot of code to re-write!)
>
> Cheers, Pete (aka lad4bear)
--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
ICQ: 3094740
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
--
[EMAIL PROTECTED]
http://blog.rawlinson.us <http://blog.rawlinson.us>
If you want Gmail - just ask.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
