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]> 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]. > 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.
