Variables and Scopes

     

Variables and Scopes

A variable is a name that represents data, in the same way that a label on a drawer represents the contents of the drawer . The value of the data is the contents of the drawer. In ColdFusion, variable values can be set and reset with cfset , or set to an initial default value with cfparam . Variables can be passed as attributes to CFML tags, or as parameters to functions.

Here's a typical cfparam tag:

 <cfparam name="BirthDate" type="date" default="January 1, 2003"> 

If there is no BirthDate variable in existence yet, ColdFusion creates one and sets its value to January 1, 2003 . If the variable BirthDate already exists, its value doesn't change.

To refer to the value stored in a variable, enclose the variable in pound signs, like this: #BirthDate# . For example, to use the cfoutput tag to display this variable, do this:

 <cfoutput>#BirthDate#</cfoutput> 

Troubleshooting with Data Type Checking

In the cfparam example, the type attribute helps you detect problems in your program by causing ColdFusion to check whether the existing value can be interpreted as a valid date. If not, ColdFusion gives you an Invalid parameter type error. In the following example, the first line creates the variable, whereas the second generates an error:

 <cfset BirthDate = "hello"> <cfparam name="BirthDate" type="date" default="January 1, 2003"> 

The following lines, on the other hand, don't generate an error:

 <cfset BirthDate = "1-1-02"> <cfparam name="BirthDate" type="date" default="January 1, 2003"> 

Error checking does not persist after the cfparam tag. So, the following generates no error:

 <cfset BirthDate = "1-1-02"> <cfparam name="BirthDate" type="date" default="January 1, 2003"> <cfset BirthDate = "hello"> 

Using cftry/cfcatch to Trap Errors

Normally, you should use the type attribute ”or any operation that may generate an error ”in combination with cftry/cfcatch , to gracefully recover from the error, or at least give users an error message they will understand.

 <cftry>     <cfparam name="BirthDate" type="date" default="January 1, 2003">     <cfcatch>         <!--- GRACEFUL RECOVERY OR MEANINGFUL ERROR MESSAGE GOES HERE --  </cfcatch> </cftry> 

Managing Variables in Scopes

All variables are stored in scopes , categories that define the accessibility and longevity of the variables. If no scope is explicitly specified, as in the examples given so far in this chapter, the variable is created in the default VARIABLES scope. (Although it is not a requirement, scopes are sometimes written in all caps, to make it easier to distinguish them from other CFML elements.)

You specify a scope explicitly by putting it before the variable, separating the two with a period: SESSION.myVar .

Other commonly encountered scopes include APPLICATION , ARGUMENTS , ATTRIBUTES , CALLER , CLIENT , FLASH , FORM , REQUEST , SESSION , and URL .

Scopes That Require Locking

There are four scopes in which data persists past the life of a single request: CLIENT , APPLICATION , SESSION , and SERVER . Because ColdFusion is multi-threaded, at any given moment ColdFusion may be processing multiple requests , even from a single client. For this reason, all four of these scopes present the danger of simultaneously trying to set a single variable to two different values, resulting in unpredictable behavior. To avoid this, use the cflock tag to enclose sections of code that change variables in these scopes. For instance:

 <cflock> <cfset application.myVar = "true"> </cflock> 

WARNING

For locking to work, all code that changes the variable must be enclosed within cflock tags. A cfset tag not enclosed in cflock tags could change a locked variable.


NOTE

Before application variables can be used, the application state management system must be enabled with the clientmanagement attribute in the cfapplication tag. For example:

 <CFAPPLICATION NAME="greendeptApp" CLIENTMANAGEMENT="Yes"> 


Scoping Out the Scopes

Variables in the ATTRIBUTES scope are available only on the page on which they are created and pages included with the cfinclude tag. (See also the CALLER scope).

CALLER and ATTRIBUTES are used only with custom tags (files that define procedures and attributes for tags that you create yourself). In a custom tag file, the CALLER scope references the VARIABLES scope of the page that called (used) the custom tag. The ATTRIBUTES scope is for variables that contain values passed by the calling page.

The cf_scrape custom tag, defined in scrape.cfm , uses both the CALLER and ATTRIBUTES scopes. See "Custom Tags," page 895 , in this chapter.


The ARGUMENTS scope contains variables passed to a user -defined function, or to a method (a function contained in a ColdFusion component).

The APPLICATION scope contains variables associated with an entire application. The application name is defined in a cfapplication tag, which the programmer usually puts in application.cfm .

application.cfm

The application.cfm file is a special page that is automatically processed before each page in the application is loaded. The application.cfm page defines application-level settings, functions, and features, such as default variables, constants, data sources, style settings, and error pages. Anything defined on the application.cfm page will always be available on all pages and to all users of the application.


The CLIENT scope contains variables associated with one client. Client variables persist across pages and browser sessions. By default, Client variables are stored in the system registry of the client computer, but you can store them in a cookie or a database.

The FLASH scope contains variables exchanged between a Macromedia Flash MX movie and the ColdFusion MX server.

For more on using Flash with ColdFusion, see Chapter 23, "Using Flash for Dynamic Data," page 661 .


The FORM scope contains variables passed from a Form page to its action page when the user submits the form.

The REQUEST scope contains variables associated with one HTTP request. The variables stored in the REQUEST scope are available to all pages processed in response to the request. The REQUEST scope is often used instead of the APPLICATION scope, so that variables don't have to be locked.

The SERVER scope contains variables available to all applications running on the server.

The SESSION scope contains variables associated with one client. Unlike Client variables, however, Session variables do not persist across browser sessions. They disappear when the user closes the browser. They can also be configured to time out after a period of inactivity.

The URL scope contains parameters that were appended to the URL that called the current page. A question mark separates the main body of the URL from the parameters. If there is more than one parameter, they are separated by ampersands ( & ). For instance:

http://www.greendept.com/index.cfm?type=" lightbulb "&item="compactfluorescent"

For a complete table of scopes, and links to information on scopes and locking, see scopes.htm on the CD accompanying this book.




Using Macromedia Studio MX 2004
Special Edition Using Macromedia Studio MX 2004
ISBN: 0789730421
EAN: 2147483647
Year: N/A
Pages: 339

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net