By Terry Ryan · dzone.com

Types

ColdFusion is weakly typed. Variables themselves have no concept of type, but the underlying data does. This means that the same variable may act as multiple classical types without having to be set for them. For example:


<cfset test = 1 />

The variable test can act like a numeric:

<cfset newTest = test + test />.

However it can also act like a string in the call:

<cfset stringLen = len(test) />.

There are two classes of variables by type in ColdFusion: Simple and Complex.

Simple

Simple variables are variables that are limited to one unstructured value. They include: String, Numeric, Boolean, or DateTime.

Complex

Complex variables are those that either contain structured elements or binary data. They include: structs, arrays, queries, XML, images, and objects.

Scopes

All variables in ColdFusion live in a scope. The scopes are just collections of variables that share similar sources or audiences. They are all ColdFusion struct variables.

Single Request Scopes

These scopes only exist for the life of one page. They can only be accessed by calls made in that page.

CGI Contains variables created by the Web server. It gives information like requesting host, ip address, and complete URI information.
Form These are values passed by a form Post to a page.
Request Prefixing variables with “request” creates this scope. It exists across all calls, functions, or custom tags, contained within one single request.
URL These are values passed by a form GET to a page or appended as a query parameter on the tail end of URL request.
Variables This is the default scope for variables in a request that are not in another scope. It is only accessible within the main flow of the request, and not directly in any other call like a custom tag or object call.

Persistent Scopes

The following scopes exists for more than the life of one request. They are often the place for storing variables which are used across the life of a user’s session or an application’s life.

Application Variables persist across the life of an application. They are accessible by any request that has the same application name.
Client Variables persist across the life of a user’s session in a particular application. They are accessible from any call for a particular user in a particular application. Unlike every other scope, its values can be stored on disk or database.
Cookie Variables persist either across the life of the user’s browser session, or according to a date that is specified when set.
Server Variables persist across the life of the server. They are accessible by any call anywhere on the server. Also contains information about the server instance of ColdFusion, like version, OS, etc.
Session Variables persist across the life of a user’s session in a particular application. They are accessible from any call for a particular user in a particular application. Unlike the Client scope, the values are stored in server memory.

Component and UDF Scopes

The following scopes are used with CFCs and user defined functions (UDFs.)

Arguments Variables that are passed in as arguments to a UDF. Values set here accessible only to the currently running call of the UDF and are therefore thread-safe.
This In CFC the variables scope is accessible externally and to any of the internal methods. It persists across the life of the instance of the CFC. Not thread-safe.
Local Private scope for a UDF. Values set here accessible only to the currently running call of the UDF and are therefore thread-safe. Created by prefixing variables with “local” or by setting with “var” keyword.
Variables In CFC the variables scope is accessible internally to the any of the methods and persists across the life of the instance of the CFC. Not thread-safe.

Custom Tag Scopes

The following scopes are used custom tags.

Attributes Variables that are passed into a custom tag. Values set here accessible only to the currently running call of the custom tag and are therefore thread-safe.
Caller An alias for the variables scope of the calling page of a custom tag.
Variables The default scope for variables in a custom tag. Values here are only accessible in the custom tag itself.

Variables do not have to be explicitly scoped when referenced, but this is usually preferable for readability and performance. An unscoped variable call searches the following scope for existence:

Local (UDFs and CFCs only) Arguments (UDFs and CFCs only)

  1. Variables
  2. CGI
  3. URL
  4. Form
  5. Cookie
  6. Client

Session, Application, Server, and Request scopes will not yield their values without an explicit reference to them.

Types of ColdFusion Files

Page

A page is your basic ColdFusion file. Its file extension is “.cfm.”

Here is a traditional “Hello World” page.


<cfset variable = “Hello World” />
<cfoutput>#variable#</cfoutput>

Custom Tag


A custom tag is a special type of page. It encapsulates
commonly used code, and allows you to call it using
<cfmodule>, or with the prefix <cf_. Its file extension is “.cfm.”

Here is a basic custom tag named DisplayDate.cfm:


<cfparam name=”attributes.date” default=”#now()#”/>
<cfoutput>
<p>#DateFormat(attributes.date, “mmmm d, yyyy”)#</p>
</cfoutput>

It takes a date that is passed in and formats it. If no date is passed in it sets the date to Now().

You would call it like this:


<cf_displayDate >
<cf_displayDate date =”#CreateDate(2009,7,8)#”>

It would display like this:

July 15, 2009

July 8, 2009

Component

A ColdFusion Component, or CFC for short, is a collection of properties and UDFs wrapped together. It is analogous to but not exactly the same as a Java Class. Its file extension is “.cfm.”

As of ColdFusion 9, properties yield implicit getters and setters.

They can be defined either in CFML:


<cfcomponent>
<cfproperty name=”firstName” />
<cfproperty name=”lastName” />
<cfproperty name=”email”/>
<cffunction name=”getDisplayName” returntype=”string”>
<cfreturn This.getFirstName() & “ “ & This.getLastName() />
</cffunction>
</cfcomponent>

Or in CFScript:


component{
property firstName;
property lastName;
property email;
string function getDisplayName(){
return This.getFirstName() & “ “ & This.getLastName();
}
}

Either version of the CFC would be called like this:


<cfset person = New cfcScriptExample() />
<cfset person.setfirstName(‘Terry’) />
<cfset person.setlastName(‘Ryan’) />
<cfset person.setEmail(‘[email protected]’) />
<cfoutput>
<p>#person.getDisplayName()#</p>
<p>#person.getEmail()#</p>
</cfoutput>

And they would display this:

Terry Ryan

[email protected]

Application Framework

ColdFusion code is packaged into Applications. Applications are comprised of folders, files, and an Application.cfc. The Application.cfc stores settings that allow a developer to handle the behavior of applications, sessions and requests. There are a number of methods that ColdFusion can respond to in this file:

onApplicationEnd Is not triggered when the application times outs or the server shuts down gracefully.
onApplicationStart Is triggered the first time an application is called. You can use this function to initialize application variables.
onError Is triggered whenever an uncaught exception is raised anywhere in the application.
onMissingTemplate Triggered whenever a request is made for a cfm or cfc that doesn’t exist in the application. Can be used to simulate virtual files.
onRequest Replaces a request. If you use this method, you have to explicitly include the intended page or cfc. Useful for wrapping layout and formatting features around an application.
onRequestEnd Triggered by the end of a request.
onRequestStart Triggered by the start of a request.
onSessionEnd Triggered the first time a particular user calls a URL in the application. Useful for setting session scoped variables.
onSessionStart Triggered when user session ends, usually because the session timed out.

Read the original on dzone.com ↗