Starting with CF 6, most scopes became structures - objects with members - but in the pre Java days of ColdFusion there were a good many differences in how various scopes behaved. Few things were objects or structures. All those neat little structure functions that are so darn useful when dealing with a scope were not invented yet. Instead we had famously ugly, workaround code with loops using lists and evaluate( ). You might remember the good old CF 4.x days when, in order to loop through form variables, you used the "special" form variable called fieldnames which contained all the form field names. Remember this code?
In fact, the special "fieldnames" form element did not disappear until ColdFusion 8 - for backward compatibility reasons I'm sure. Even back then we tried to avoid the use of the "Evaluate( )" function which was an expensive tag to be sure if you were concerned about performance. I remember that Ray was famous for going apoplectic whenever anyone suggested it as a solution. But because of how each scope was sort of special, evaluate() was occasionally unavoidable. Now days, the code above can be done using object notation and it is much cleaner.
One exception to the all-scopes-behave-the-same rule is the "CGI" scope. Now CGI is a useful scope for quite a few things. You can determine the IP address of the requesting device. You can check the user agent to see if the device is a smart phone browser - useful if you want to display a link to your new "mobile" application. You can check to see what port they are using and enforce SSL for a certain page or section. These and many other things can be done by unpacking the data in the CGI scope.
One of the things to keep in mind about the CGI scope is how it comes to be. CGI contains variables that are aggregated from more than one source. Not everything in the CGI structure (oh yes, it's still a structure) comes from the browser. Things like the user agent, query string, cookies etc all come from the browser - or more specifically from the header of the HTTP request. But things like the Path_translated (which is the physical path of the template) and Server_software (apache, IIS etc) come from the web server. I'm not even sure where items like certificate information and IP addresses come from but I suspect they also come from the web server.
Under the hood the web server actually cobbles this list of variables together by analyzing the HTTP request and combining it with some info it "knows" about itself and the underlying networking, and then passes it as data to the ColdFusion engine which then handles the request, produces output, and sends the output back to the web server, which delivers it back to the browser (whew!). In fact, when you think about it, the CGI scope contains in all practicality everything ColdFusion needs to process the request. It has the location of the file being called, the query string etc. The only thing it is missing is the "content" area of the HTTP request (where things like form elements are passed).
Ok, so the source of the data is varied, it is organized by the web server and passed to ColdFusion. It's still just a structure right? Well yes, it is a structure. Code like this works fine.
For example, an "Undefined" Form Variable Throws an Error.
One reason this is important is debugging. Since CGI variables are blithely treated as if they exist, there are cases where you might have trouble finding certain kinds of errors in logic. Take spelling for example (or should I say "tkae speellign fro exmaple"). If you are including logic blocks that use CGI variables make sure and watch out for spelling. Say you do something like the following:
Happy coding and as always I the Muse welcomes all polite comments :)