This chapter is from the book
This chapter is from the book
This chapter is from the book
Retrieving Values
To use variables in a particular scope, you add the name of the scope to the beginning of the variable's name and separate the two with a dot. For example, to output a form variable called LastName, you would use the following line of code:
<CFOUTPUT>Last name submitted: #FORM.LastName#</CFOUTPUT>
This is referred to as dot notation. If you leave off the scope name, your code will probably still work (most of the time), but it will be less efficient. By adding the scope prefix to the variable name, you are telling ColdFusion where to look for that variable. If there is no scope prefix, ColdFusion must search through all of the scopes until it finds the variable. If ColdFusion comes across a variable without a scope prefix, it will look through the various scopes in the following order of precedence.
Variables (local)
CGI
URL
Form
Cookie
Client
As you can see, you can save processing time by telling ColdFusion that a particular variable lives in the Form scope rather than letting ColdFusion search through all scopes.
There is a pitfall to be aware of when using variables. It is possible to create two variables with the same name but different scopes in the same template. For example, imagine you have a template that processes data submitted by a form and you inadvertently create a local variable in that template with the same name. In the code
<!––– check for value from form –––> <CFPARAM Name="FORM.Qty" Default=10> <!––– set local variable –––> <CFSET Qty=2> <!––– output variable –––> <CFOUTPUT>Quantity ordered is #Qty#.</CFOUTPUT>
we use <CFPARAM> to check for the existence of an incoming Form variable called Qty. If it does not exist, we set the value to 10. Next, we create (by mistake) a local variable called Qty and assign it the value of 2. We have now ended up with two variables with the same name. We then use <CFOUTPUT> to display the value of the variable. However, because we have not specified a scope prefix in the <CFOUTPUT> block, ColdFusion starts to search for the variable using the order of precedence previously listed. It first searches the Variables (local) scope, finds a Qty variable there, and outputs the value 2.
If we wanted to make sure we used the value from the submitted form, we would change the last line of code to read as follows:
<CFOUTPUT>Quantity ordered is #FORM.Qty#.</CFOUTPUT>
ColdFusion would then know exactly in which scope to look for the Qty variable. Our template would then display the value from the submitted form, or the default value of 10.
The moral of the story is to always use prefix scopes on all variables other than local variables.
NOTE
You might have noticed that the first scope listed in the search order is the Variables scope, which is the scope for local variables. So, if we wanted to be as correct as possible when using local variables, our code would read something like this:
<CFSET Variables.Age="30"> <CFSET Variables.YearsOverTheHill= Age - 21> <CFOUTPUT>#Variables.YearsOverTheHill#</CFOUTPUT>
However, because the Variables scope is the first one searched in the order of precedence, there is no real savings in processing time, and most developers leave off the scope prefix for local variables. We are a lazy bunch when we can get away with it.