Sorry, I was just looking at the last message. He's var'ing the query to make sure it's in the local scope, just as with the variables.
On Tuesday, June 24, 2014 12:42:13 PM UTC-5, Jason Allen wrote: > > I'm trying to grasp WHY i need to do that.. Ricky suggested I add the > QueryNew line, but didn't show what to do with it/why. > > I'm not sure what I need to do and what the purpose is. Do I need to > define my entire query? Is that really necessary? > > > > > > On Tue, Jun 24, 2014 at 12:26 PM, Marcus F <[email protected] > <javascript:>> wrote: > >> Take a look at the OpenBD docs, they're often more clearn than ACF's docs. >> >> http://openbd.org/manual/?/function/querynew >> >> >> On Tuesday, June 24, 2014 12:09:26 PM UTC-5, Jason Allen wrote: >> >>> 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] <javascript:>. >> 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.
