By: Mary Horvath, Allaire Documentation Group

This technical note describes ColdFusion expressions -- language constructs that allow you to create sophisticated applications.

Click here to download the pdf version of this document.

Contents

Section A

• Elements of ColdFusion Expressions
• Operands: Data Types, Constants, and Variables
• Data Types of Constants and Variables
• Constants
• Variables

Section B

• Operators
• Operator Precedence
• Functions as Operators
• Pound Signs

Section A—Read below.
Section B—Click here to read.

Elements of ColdFusion Expressions

ColdFusion expressions consist of operands and operators. Constants and variables comprise the operands. Operators are the verbs that act on the operands; functions are a form of operator. This chapter first describes the operands and then describes the operators.

Operands: Data Types, Constants, and Variables

The sections on operands provide detailed information on the following:

• Data types of ColdFusion operands
• ColdFusion constants
• ColdFusion variables: naming conventions, kinds of variables, scoping, and other relevant details

Data Types of Constants and Variables

In ColdFusion, constants and variables have implied data types. The reason for the term "implied" is that there are no variable declarations that define the scalar data type of a variable as one finds in statically typed languages such as Pascal. Whenever you use a constant or set the value of a variable, the value you use has a type, be it integer, real, or string. For example, if you use CFSET to create a variable AGE and set its value to 62, the implied data type is integer. In addition to these scalar types, ColdFusion also supports lists, structures, and arrays. The following table describes the types of variables and constants you can use in a ColdFusion application page.

"the ""best"" software"

"use a pound sign (##) here"

"October 30, 1999"
"Oct 30, 1999"
"Oct. 30, 1999"
"10/30/99"
"1999-30-10"

"October 30, 1999 02:34:12"
"October 30, 1999 2:34a"
"October 30, 1999 2:34am"
"October 30, 1999 02:34am"
"October 30, 1999 2am"

<CFSET myarray[1][2]=Now()>

<CFQUERY NAME=myquery
    DATASOURCE=mydata
    SELECT * FROM CUSTOMERS
</CFQUERY>

<CFSET myquery2=myquery>

<CFSET temp=Mailer.SendMail()>

<CFSET Mailer.FromName=Form.fromname>

Notes on date-and-time values

There are a variety of ways in which a date-and-time value can be entered in ColdFusion. You can use the functions that create date-and-time objects using various criteria.

How date and time values are stored

Internally to ColdFusion, date-and-time values are represented on a time line as a subset of the real numbers. This is done for efficiency in evaluation and because it directly mimics the method used by many popular database systems, including Microsoft Access. One day is equal to the difference between two successive integers. The time portion of the date-and-time value is stored in the fractional part of the real number.

Thus, arithmetic operations can be used to manipulate date-and-time values. For example, Now() + 1 will evaluate to tomorrow at the same time. However, we strongly discourage ColdFusion developers from using this potentially troublesome method of manipulating date-and-time objects. Date-and-time manipulation routines should be used instead.

21st century dates

Two-digit years from 00 to 29 are treated as 21st century dates; 30 to 99 are treated as 20th century dates.

"October 30, 2015"
"October 30, 15"

Fast Date/Time parsing in UNIX

On UNIX, there is a switch that provides fast date/time parsing. If you have enabled this switch, you must refer to dates in expressions in the following order: month, day, and year. For example:

<CFIF "11/23/1998" GT "11/15/1998">

If this switch is set, the default date format returned by the DateFormat() function cannot be parsed in an expression. However, to parse this date specify a mask indicating the correct order, such as, mm/dd/yyyy.

The Fast Date/Time Parsing switch is set on the ColdFusion Administrator Server Settings page. Refer to Administering ColdFusion Server for more information about ColdFusion settings.

Constants

Constants are simple scalar values that you can use within expressions and functions. They include integers, real numbers, time and date values, boolean values, string values, and lists. Constants do not include more complex values, such as structures and arrays, because arrays and structures are created as variables.

Variables

Variables are the most frequently used operands. Unlike constants, which always have the same value, their values can be set and reset, passed as attributes to CFML tags and JRun servlets. Like constants, they can also be passed as parameters to functions, and can replace most constants. The following sections discuss:

• Variable naming conventions
• Kinds of variables
• Qualifying, or scoping, variable references
• Performance and scoping
• Order of ColdFusion variable look-ups
• Variables across application pages
• Variables stored in structures

For a comprehensive list of all of the variables associated with ColdFusion, see Quick Reference to CFML.

Variable naming conventions

When naming ColdFusion variables and form fields, keep these guidelines in mind:

• Variable names must begin with a letter, which can be followed by any number of letters, numbers, or the underscore character.
• Variable names must be all one word.
• Do not use spaces or special characters in variable names.
  For example, UserName_1, UserName2, and User_Name are valid, but 1stUser, WhatAName!, and User-Name are not.
• For field names and variables, use descriptive names, not abbreviations. It will be much easier for others to read your code, and for you to remember how it works yourself, when you revisit it months later.
• Queries and variables cannot have the same name in the same ColdFusion application page.
• Although ColdFusion variables are not case-sensitive, keep capitalization consistent in order to keep your code consistent.
• In writing queries and forms, match your form field names with the corresponding database field name.
• In some cases, a variable must have pounds signs around it to allow ColdFusion to distinguish it from string or HTML text and to insert its value as opposed to its name. For more information on how to use pound signs in expressions see Pound Signs.

Kinds of variables

ColdFusion supports several kinds of variables. This section describes the kinds of variables available and how you use them.

The following table describes the types of variables you can use in a ColdFusion application page.

The section Order of ColdFusion variable look-ups describes the order in which ColdFusion finds variables in application pages.

Qualifying, or scoping, variable references

ColdFusion distinguishes between identically named parameters from different sources with a specific prefix for each source or "scope." For example, to specify a variable called State that is passed in a form submission, you would use Form.State. To specify a variable named State passed in a URL, you would use URL.State.

Although you aren't required to use the prefix unless two variables in different scopes have the same name, for readability and processing speed, it is recommended that you use prefixes. For example, the variable "Form.lastname" is far more self-evident than a variable called "lastname."

The following chart shows the prefixes for each variable type:

Many of the CFML tags have variables associated with them, such as CFERROR and CFFTP. Typically, these variables use the tag name as the prefix. For a complete listing of these variables, and all other variables mentioned in this Technical Note, see Quick Reference to CFML.

Performance and scoping

You can improve performance by always qualifying your variables with the proper scope. Adding variable scopes improves processing speed but the trade-off is that it may not be so easy to reuse the same code in other applications or pages.

In the following example, both forms of the following 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>

Order of ColdFusion variable look-ups

When scoping is not used, that is, when you don't include a variable prefix, such as "Form.myformvar," ColdFusion attempts to find variables in the following order:

1. Local variables created using CFSET and CFQUERY
2. CGI variables
3. File variables
4. URL variables
5. Form variables
6. Cookie variables
7. Client variables

Variables across application pages

Within ColdFusion, most variables apply only to a single template. However, several types of variables can be used across multiple application pages:

• Client variables store identifying information about an individual client.

  Client variables are designed to hold long-term information particular to an individual client. You can store client variables in the system registry, a database, or in a cookie named for the application.

• Server variables are valid for all ColdFusion applications on a particular server.

  Server variables are used to store information (typically read-only) that does not change often and can be shared across many users and ColdFusion applications.

• Session variables are valid for as long as an individual Client ID maintains a session.

  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 valid for a specified application.

  Application variables are available to individual, specified applications and to all users of that application who access your ColdFusion server. They are stored in the server's memory and can be set to time out at specified intervals. Application variables are general and available to all users.

• Caller variables are valid for ColdFusion custom tags.

  Caller variables are available for passing information among application pages for a ColdFusion custom tag.

See the description of CFAPPLICATION for information on setting up client state management using the CLIENTMANAGEMENT attribute in the CFAPPLICATION tag. See also Developing Web Applications with ColdFusion for information about using Application, Client, and Session variables.

Variables stored in structures

As of ColdFusion 4.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 one structure, all parameters passed on a URL as a structure, and so forth.

Structures can be accessed using any of the ColdFusion structure functions, and in the form structname.key, where each key represents a field name of a form or a variable name of a specific type. Because these structures are formed by ColdFusion whenever these variables are used, it makes conversion into WDDX particularly straightforward, if you need to package variable/form data into WDDX. For example:

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

Click here to continue reading.