In our continuing quest, to upgrade Legacy Code to the modern age, we continue our discussion on scoping. As previously noted, you should explicitly scope each and every variable. Aside from the performance gains made, it will also make your code easier to follow, to find where each variable is set and changed. To date we've talked about the primary persistent scopes, the "passalong" scopes, the scopes used with Custom Tags, and those scopes used in CFCs. In this post we're going to talk about a few of the remaining scopes (and in some cases, non-scope scopes).

CLIENT
- This scope is a persistent scope, and the reason that I did not bring it up before is because of the overhead associated with using it. The CLIENT scope stores its data in one of three places: the Registry, Cookies, or a database. All of these methods have their own pros and cons, but ultimately CLIENT storage access can be a significant hit to application performance, especially if managed poorly. The CLIENT scope isn't all bad, being a valuable tool for simple variables in clustered environments (for example), but it does come with a cost, which should factor heavily into any decision making over whether to use it or not.

It isn't very common to use the CLIENT scope today, but I do bring it up because of the amount of Legacy Code that does exist using it. You will want to thoroughly consult the ColdFusion Documentation on its use, and weigh the trade off's involved. There are a lot of caveats around the different types of storage, and you should also review the documentation on the CLIENT settings in the CF Admin.

CGI
- When the browser requests a page, the web server and the browser pass along certain environmental variables back to ColdFusion. It is possible to use these variables for very valuable information, like whether its an HTTPS request, or what the actual domain name is. One important thing to note, when using CGI variables, is that different web servers can (and do) use different keys for the same information. What this means is, if you happen to be using PKI client certificates for authentication to your application Apache will pass those credentials in a completely different key than IIS would, and different versions of IIS may use different keys as well. If your application is portable (designed for deployment on multiple platforms), you'll want to be very careful in determining your use cases.
COOKIE
Just like it sounds, this scope is to get or set browser cookies. It takes simple name/value pairs. Using the COOKIE.somevar = "something" syntax will create the key/value in a cookie for the application's domain in the browser. For a finer level of control (setting expiration, etc) you are still nailed to use <:cfcookie> in its tag form. (I'm hoping this will change in the future.)
THREAD
- Threads are still relatively new to ColdFusion, allowing you to write multi-threaded processes. You won't run into Thread code prior to CF 8. Threads actually have three scopes: THREAD, Thread local, and Thread attributes. I'm not even going to touch on scoping of Threads, referring you instead to the ColdFusion Documentation on Working with Thread Data.
Unscope Scopes - Query, CFFile, CFCatch, etc
- There are several scopes that aren't really scopes, so much as data returned during the process of certain tag processes. You always want to prefix access to these variables. See the ColdFusion Documentation for details on each one individually

This post wraps up our review of the different scopes, and their use cases, so that you may more effectively explicitly scope every reference, and use the right scope in the right scenario. There are exceptions to most use case rules, and you will have to make the determination if it's worth making those exceptions. Scoping an entire application can take a great deal of time, and is generally done in small pieces, testing each change along the way. Source Control branching strategies are invaluable at this stage of development.

During our next post, we'll discuss how you might go about new product development, and existing product maintenance, during the process of upgrading your Legacy Code applications.

This article is the fourteenth in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.