The final type of variable that we will discuss in this chapter is the cookie variable. These variables reflect the HTTP cookies passed from the browser to the server along with the request for a template.
These HTTP cookies have nothing to do with their edible namesakes. Rather they are information stored by the server in a client browser for future use.
Here’s how a cookie works:
1. TIle client requests a template.
2.When the template returns the page it includes commands in the header to store A one or more cookies indicating which documents the template is related to and the life span of the cookies.
3. In the future, when the client requests a template for which a cookie has been set (and which hasn’t expired), the cookie is sent, to the server along with a request for the template. ”
4. The server makes the cookie available to ColdFusion for use while processing the requested template
The CFCOOKIE tag is used to create cookies on the browser. Before looking at the details of cookies and how to create them consider a few of the following limitations
• Not all browsers support cookies. Current versions of Netscape Communicator and Navigator and Microsoft Internet Explorer do, but earlier versions that are still in use don’t, and other browsers still don’t offer cookie support. This limits their usefulness (as compared with’URL parameters) for passing information from page to page within a site in a browser-independent manner.
• There are limits on the number of cookies that can be set. A server can set only 20 cookies in a client browser with newer cookies replacing older ones as this limit is crossed. This means that if you have many applications on your server that set cookies, it is quite possible that cookies set by one application will be overwritten by another application.
• Cookies have a length limit of 4,096 characters (4KB). This length includes the value, name, and additional information, such as the expiration date. Effectively, this means the actual value stored in the cookie needs to be less than 4KB in length
Keeping these limits in mind we will now discuss the process of cookie creation. When creating cookies several pieces of information can or must be provided. These are outlined in the following list
Cookie name This is required when creating a cookie. All cookies must have a name.
Cookie value The value to be assigned to the cookie can be specified at the time of creation. This is optional; however, an empty cookie can be created.
Expiration date Cookies have a life span that can be indicated at the time of creation by an expiry date. You do not have to specify an expiration date, and if you choose not to, then the cookie will expire once the client browser is closed.
Security status It is possible to indicate that a cookie must be transmitted over Secure Sockets Layer (SSL)-encrypted Web connections.
Path Cookies can either be related to all documents in a given Web site or can be associated with specific documents in a site.
Domain name Cookies are associated with specific Internet domains, and the domain name ensures that cookie data rs sent only to the correct servers.
These pieces of a cookie definition are translated directly into attributes of the CFtOOKIE tag. The CFCOOKIE tag takes six possible attributes:
NAME Required attribute specifying the name of the cookie.
VALUE Optional attribute setting a value for the cookie.
EXPIRES Optional attribute specifying the expiration of the cookie. This can be specified as a date (such as 1/2/99), a number of days (such as 53), or as one of two keywords: NOWor NEVERI.f you set the expiration to NOWfor an existing cookie, you can effectively delete an existing cookie.
SECURE Optional attribute indicating whether the cookie requires a secure connection for transmission. Possible values are YES and NO
PATH Optional atttibute specifying a subset of documents on a server to which the cookie is associated. These are specified as paths relative to the root directory of the Web server (such as /some/path). Multiple paths can be indicated, separated by semicolons.
DOMAIN Optional attribute specifying the domain to which the cookie can be sent. Explicit domains (such as enn. com)should be preceded by a period (dot); for example cnn . com.Specific hosts are specified without the leading dot, as in wvtN. cnn. com.
To fully understand how this works, consider the following series of CFCOOKIE tags:
<CFCOOKIE NAME-‘Cookiel’ VALUE-‘Valuel’>
<CFCOOKIE NAME-‘Cookie2’ VALUE-‘Value2’ EXPIRES-‘S3’>
<CFCOOKIE NAME-‘Cookie3’ VALUE-‘VallJe3’ EXPIRES-‘ 22 PATHm’/some/other/path’>
So what does this all mean? We will discuss them in the following list:
• Cookies1 will be sent with all requests for documents from the Web site that set the cookie until the user closes the browser that the cookie was originally set in.
• Cookies2 will be sent with all requests for documents from the Web site that set the cookie for 53 days from the time that it is created.
• Cookies3 will be sent with all requests for documents on the two specified paths from the Web site that set the cookie for 22 days from the time that it was created.
Referencing Existing Cookies
Now that you know how to set cookies, you must consider how to access those variables in templates. After all, the whole point of setting cookies is to use them when the browser returns them with a request for a template. Otherwise they serve no real purpose.
As you might expect at tlus point, accessing variables can be done by adding COOKIE. to the beginning of the name of the cookie. Therefore, the preceding examples can be accessed as COOKIE.Cookies 1, COOKIES .Cookies 2 and COOKIL Cookies 3
CFPARAM and Default Variables
The CFPARAMtag provides a way to test whether a given variable exists and, if not, to eate it and assign it a default variable. this is a useful capability.
Consider a simple example: You have created a template that mayor may not be accessed with a URL parameter called Info. If the parameter exists, then it will be used in the processing of the template. If not, a default value will be used.
One way to achieve this is through the following approach:
<CFSET URL.lnfo – ‘Default’)
What you have done here is use the ParameterExi sts function to test whether URL.Info exists. If it does, the Boolean value True is returned; otherwise, False is returned. You use this function in a CFIF tag, as discussed in Chapter 7, so that if the parameter doesn’t exist, you can assign a default value to the variable URL.Info.
However, this requires the use of two tags (CFIF and CFSET)and a function (ParameterExsts). The same result can be achieved with the CFPARAMtag, which wraps the entire procedure into a single tag. The CFPARAMtag takes the following form:
<CFPARAM NAME-‘variable name’ DEFAULTc’defau7t value’)
Here, the value specified by the NAMEattribute is the name of the variable to check, and the value of the DEFAULTattribute is the value to be assigned to the variable if i. doesn’t exist and needs to be created. This means that your previous three lines of code become one, to look like the following
<CFPARAM NAME-‘URL:lnfo’ DEFAULT-‘Oefault’)
Where Do We Go from Here ?
In this chapter, you have learned about variables. Variables are essential to the development of powerful efficient and easy-to-understand templates.
Having mastered creating and referencing variables you are now in a position to use them in several waye including as parameters to functions as the building blocks for expressions and as the data used to control the flow of code in your templates
In the next chapter you will look at functions. Common to many programming languages functions provide a way to isolate programming code into a virtual black box which given data as input-performs an expected action and returns the results as output.
ColdFusion offers developers a rich array of built-in functions that you will consider in the next chapter; you will also learn the mechanics of using functions in your templates.