RE: [CFCDev] cfc scope issues

[Jean Moniatte]

There is a trick mentionned by someone of the list a while ago:   Define <cfset var local = structNew()> at the top of your method. Wherever you need a var scoped variable (does not need to be at the top), you can then use <cfset local.x = 0>.   Jean From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hamoud, Ryan N. Sent: Friday, March 10, 2006 9:28 AM To: CFCDev@cfczone.org Subject: RE: [CFCDev] cfc scope issues So var scoping has to be done at the top of methods right? So how do var scope for a situation when you don't actually cfset the variable till the end of your method. The only reason I came across this is when I was validating all my arguments at the top and then near the bottom I finally set my variable that I wanted to retune.   Here is a example of what I am referring to.   <CFFUNCTION NAME="tableSearch" access="remote" returntype="string">   <CFARGUMENT NAME="searchFor" type="string" required="yes">   <CFARGUMENT NAME="tableName" type="string" required="yes">   <CFARGUMENT NAME="fieldToSearch" type="string" required="yes">   <CFARGUMENT NAME="returnField" type="string" required="yes">   <CFARGUMENT NAME="searchFieldType" type="string" required="yes">      <cfset var getValues = "" />      <cfif not IsDefined("ARGUMENTS.searchFor")>    <cfabort showerror="The searchFor attribute is not defined, cannot process this tag.">   </cfif>   <cfif not IsDefined("ARGUMENTS.tableName")>    <cfabort showerror="The tableName attribute is not defined, cannot process this tag.">   </cfif>   <cfif not IsDefined("ARGUMENTS.fieldToSearch")>    <cfabort showerror="The fieldToSearch attribute is not defined, cannot process this tag.">   </cfif>   <cfif not IsDefined("ARGUMENTS.returnField")>    <cfabort showerror="The returnField attribute is not defined, cannot process this tag.">   </cfif>   <cfif not IsDefined("ARGUMENTS.searchFieldType")>    <cfabort showerror="The searchFieldType attribute is not defined, cannot process this tag.  Please supply either text or integer">   </cfif>    <cfif ARGUMENTS.searchFieldType is "text">    <cfset ARGUMENTS.searchFor = "#listChangeDelims(ARGUMENTS.searchFor,"','")#">   </cfif>      <cfquery name="getValues" datasource="#request.app.DSN#" blockfactor="5" cachedwithin="#request.app.queryCache30#">      blah blah blah b;ah  </cfquery>      <cfif getValues.recordCount>    <cfset out = ValueList(getValues.myfield,',&nbsp;')>   <cfelse>    <cfset out = "">    </cfif>   <CFRETURN out />  </CFFUNCTION>       -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Nando Sent: Friday, March 10, 2006 11:07 AM To: CFCDev@cfczone.org Subject: Re: [CFCDev] cfc scope issues That's a little obscure. You're var scoping that variable by simply setting it to an empty string before you effectively reassign it as the query name in the cfquery tag. You could also do <cfset var coreLV = queryNew(columnlist [, columntypelist]) >, but it's easier to just let ColdFusion dynamically reassign it. It's important particularly to var scope variables like this so they don't wind up in the variables scope of the CFC and possibly cause unintended consequences. Sometimes it doesn't make any difference, but when it does, it's very difficult to debug, because the problem is quite hidden. So it's better to make sure you always var scope local variables. It's kinda similar to how you can affect a .cfm template where you have a local variable set on the page. Something like: <cfset myName = "Joe" > If someone messes with the query string in the url and adds &myName=Tommy to the end, myName changes, and that can mess things up. If instead, you place myName in the request scope : <cfset request.myName = "Joe" > it can't be unintentionally affected by url or form scopes. var scoping your local variables in your functions follows the same principle. It ensures the function is encapsulated so that any variable assignments that happen within it do not affect anything else (and perhaps visa versa). Once you get into more heavy duty CFC use, serious problems can arise from neglecting this small detail. :) Nando Hamoud, Ryan N. wrote: OK this all makes a little more sense...... 1 question I have is why are you guys defining coreLV like this <cfset var coreLV = ""> I am just trying to make sure I am on the same page with everyone.  coreLV is a constant that is set on another page before it enters my cfc   ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org