Hi Ricky, You mentioned that after my arguments, I should add the querynew statement.
<cfset var redirectLookup = QueryNew()> I did this, and now I'm getting the following error: Expression Error; Problem occurred while parsing: var redirectLookup = QueryNew(); The function querynew requires at least 1 argument(s). I'm reading the following and I'm not grasping why I need this there, and what I can do to make it work properly. http://help.adobe.com/livedocs/coldfusion/8/htmldocs/help.html?content=functions_m-r_19.html On Thu, Jun 19, 2014 at 11:02 PM, Rawk <[email protected]> wrote: > That's really up to personal preference. My preference is to avoid using > direct "local." assignments. The only advantage I see to using the local > scope explicitly is that you can maintain the same variable name between > your arguments and local scope. However, you'd generally only need to do > that if you want to manipulate the content of the arguments variables > before using them while still maintaining that content in it's original > form. > > Not sure I explained that well.... Take your function, for example. You > only make use of your arguments once in the SQL. If you were to assign > those to the local scope, the only thing you would accomplish is adding 2 > lines of code with no actual advantage. Neither the local or arguments > scopes are accessible outside of the function, so functionally, they are > both in a local scope. > > Now let's assume you want to do some basic sanitation of your arguments > before sending them to your database. Additionally, you want to write to a > log file tracking how much sanitation is being required based on user > inputs. In this case, you might want to put your arguments in a local > scope. For example: > > <cfset local.domain = Trim(arguments.domain)> > <cflog file="sanitationLog" message="#Len(arguments.domain) - > Len(local.domain)# character difference for #local.domain#"> > > Again, this is only necessary if you want to maintain the same variable > name between both scopes AND you want to keep track of the before and after > values of your arguments. In the above example, if you didn't need to log > the character difference, you could just manipulate the arguments scope > directly: > > <cfset arguments.domain = Trim(arguments.domain)> > > Putting this all together, if you want to maintain consistent coding > patterns, there's 2 ways to approach this: > 1. local scope all arguments and type "local." every time you want to > use a variable in a function (even for variables that were not arguments) > 2. use different names in the local scope (using "var") when you want > to manipulate and keep track of original argument data. example: > <cfset var aDomain = Trim(arguments.domain)> > > It's my opinion that option 2 ultimately yields less code and less code is > nearly always cleaner. In most cases, I have no need to know the original > values in my arguments variables, so I just manipulate the arguments scope > directly, so it's a lot less common that I have to create additional > variables inside of a function just for my arguments. > > On a side note, speaking of input sanitation, there's something I should > have mentioned in my original reply. It's a good idea to get in the habit > of using the cfsqltype attribute in cfqueryparam tags. This adds another > layer of protection against SQL injection because CF will throw an error > before executing any SQL if the actual data type of the value doesn't match > the expected data type specified in in the cfsqltype attribute. As a > bonus, this ensures proper usage of single quotes in the SQL based on the > data type. > > > On Thursday, June 19, 2014 8:23:16 PM UTC-4, Jason Allen wrote: >> >> Another question >> >> I recall reading that in a cfc you should declare a local variable for >> each argument, set the local var equal to the argument, and then proceed to >> use the local var for the rest of your operations. Is that true? >> >> ie: >> >> <cfset var local = structNew()> >> <cfset local.userID = "#arguments.userID#"> >> >> <cfif local.userID eq '1'>....... >> > -- > -- > online documentation: http://openbd.org/manual/ > http://groups.google.com/group/openbd?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Open BlueDragon" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
