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