Variables are the most frequently used operands. Variable values can be set and reset, and passed as attributes to CFML tags and JRun servlets. They can be passed as parameters to functions, and can replace most constants.
For a list of the variables associated with ColdFusion, see the CFML Quick Reference.
When naming ColdFusion variables and form fields, keep these guidelines in mind:
The following table describes the types of variables you can use in a ColdFusion application page.
Variable Type |
Description |
---|---|
Query Result |
Results of a database query can be used as dynamic parameters. For example, if you create a query named LookupUser that finds the ID for a given user name, you can use this ID in another query or in a call to cfoutput. |
Local Variable |
The default scope for variables of any type created with the cfset and cfparam tags. For example, <cfset A = 5> sets the variable A to 5. This variable is available only on the application page where it is created and any included pages. |
URL Parameter |
Parameters appended to a URL after the application page name in the format variablename = value. URL parameters are stored in structures. For more information, see "Variables stored in structures". |
Form Field |
The most common way of passing parameters to a page. When a user enters data in a form field, a parameter with the name of the form field is passed to the action page. Form fields are stored in structures. For more information, see "Variables stored in structures". |
Client |
Variables associated with a particular client. Lets you maintain state as a user moves from page to page in an application. Stored in the system registry by default, but you can also store them in a cookie or in a database. Client variables are part of the ColdFusion Web Application Framework. For more information, see Developing ColdFusion Applications. |
Server |
Variables associated with the current Web server. Available to all ColdFusion applications until the ColdFusion server is shut down. This server scope lets you define variables that all your ColdFusion application pages can reference. Server variables are stored in structures. For more information, see "Variables stored in structures". For information on locking server variables, see the description of cflock. |
Session |
Variables tied to an individual client that persist for as long as that Client ID maintains a session. Session variables, like current client variables, require a client name and are available only to that one Client ID. Unlike client variables, session variables are stored in the server's memory and can be set to time-out after a precise period of inactivity. Session variables are stored in structures. For more information, see "Variables stored in structures". Session variables should be locked when accessed. For information, see the description of cflock. Session variables are part of the ColdFusion Web Application Framework. This means that they are used in the context of an Application.cfm page. For more information, see Developing ColdFusion Applications and the description of cfapplication. |
Application |
Variables tied to an application as defined in the CFAPPLICATION NAME attribute, typically used in the Application.cfm file. Application variables work only if an application name is defined.Application variables are stored in structures. For more information, see "Variables stored in structures". Application variables should be locked when accessed. For information, see the description of cflock. Application variables are part of the ColdFusion Web Application Framework. This means that they are used in the context of an Application.cfm page. For more information, see Developing ColdFusion Applications and the description of cfapplication. |
Request |
Variables storing data that pertains to the processing of a request to a single page. Request variables are convenient for storing data in a structure, carried through nested tags, such as Custom Tags, and processed at once. Request variables are stored in structures. For more information, see "Variables stored in structures". |
Caller |
Variable that lets you call and use variables from the calling template in a ColdFusion custom tag. |
HTTP Cookies |
Variables stored in the browser. Available every time the browser makes a page request. You can create cookie variables with the cfcookie tag. |
File |
Read-only variables. Created when a cffile action = "upload" operation is executed. |
CGI Environment |
Every page request has several environment variables sent to it that relate to the context in which it was requested. The variables available depend on the browser and server software. For a list of the commonly used CGI variables, see "CGI Environment Variables". Note: CGI environment variables are created even when you are using a Web server that supports a server API. |
ColdFusion distinguishes between identically named parameters from different sources by using a different prefix for each source. Specifying a variable's source is known as "scoping" the variable. For example, to specify a variable called State that is passed in a form submission, you would reference it as Form.State
. To specify a variable named State passed in a URL, you would reference it as URL.State
.
Although you are not required to use the scope prefix unless two variables in different scopes have the same name, it is recommended for readability and processing speed that you use prefixes. For example, the variable Form.lastname
is clearer than a variable called simply lastname
.
Tip Specify the variable's scope prefix for all Application, Session, Server, and Request variables. |
Many CFML tags, such as cferror
and cfftp
, have variables associated with them. Typically, these variables use the tag name as the prefix. For a list of the variables, see the Quick Reference to CFML.
Note Any variable that can be created using |
The following table lists the types of variable scopes, and shows how you refer to them in your code. In addition to these scopes, there are a number of ColdFusion data structures that provide information about the results of a tag or operation. For information on special variables, see the CFML Quick Reference and the documentation of the individual CFML tags that return these variables.
You can improve performance by qualifying variables with the proper scope. Adding variable scopes improves processing speed, but the trade-off is that it may reduce the ease of code reuse.
In the following example, both forms of the fullname variable are permitted. However, the example that includes a scoping prefix will be evaluated more quickly than the unscoped example:
<cfoutput>
#Client.fullname# #fullname# </cfoutput>
When a variable does not have a scope prefix, ColdFusion searches for it in the following sequence:
cfset
and cfquery
Note ColdFusion does not attempt to automatically find Application, Session, Server, Request, or CFML tag variables (except File variables). You must use prefixes with these variables. |
The following scopes are exposed as ColdFusion structures:
Note Variables on one application page can be used on any other application page that is included with the |
Most ColdFusion variables apply only to a single application page. However, several types of variables can be used across multiple application pages:
Client variables hold long-term information about an individual client. You can store them in the system registry, a database, or a cookie named for the application.
Server variables store information (typically read-only) that does not change often and can be shared across users and ColdFusion applications.
Session variables are useful for storing short-term information needed for a single site visit or set of requests. They are specific to individual users.
Application variables are available to individual, specified applications and to all users of that application who access the ColdFusion server. They are stored in the server's memory and can be set to time out.
Caller variables are available for passing information among application pages of a ColdFusion custom tag.
Note When variables are available to several application pages, keep track of your variable names. For more information, see "Variable naming conventions". |
For information on setting up client state management using the clientManagement
attribute in the cfapplication
tag, see the description of cfapplication. For information about using Application, Client, and Session variables, see Developing ColdFusion Applications.
As of ColdFusion 5, Form, Application, Session, Server, Request, and URL variables are stored in structures. Thus, you can reference all of the fields taken from a form as a structure, all parameters passed in a URL as a structure, and so forth.
You can access structures using any of the ColdFusion structure functions in the form structname.key, where each key represents a field name of a form or a variable name of a specific type. Because ColdFusion creates these structures whenever these variables are used, conversion to WDDX is straightforward.
<cfif
isDefined("form.submit")>
<cfwddx action = "CFML2WDDX" input = "#form#" output = "formscope"> <cfoutput>#formScope#</cfoutput> </cfif> <cfoutput> <form method = "post" action = "myForm.cfm"> <input type = "Text" name = "Title"><br> <input type = "Text" name = "URL"><br> <textarea name = "teaser" rows = "3" cols = "40"></textarea> <br> <input type = "Submit" name = "submit" value = "Submit"> </form> </cfoutput>
Note Do not use StructClear to clear session and application variables. This can cause the loss of SessionID, CFID, CFTOKEN, and application variables. To prevent this loss, store session data in |