ColdFusion has been around for nearly 10 years and has become more and more popular among web development teams every year. Fortune 500 companies as well as small development shops use ColdFusion not only because of its rapid application development features, but also because it is simply one of the more powerful web development language/application server combinations available.
You control how the host environment, the ColdFusion web application server (or just ColdFusion Server), behaves using the new ColdFusion Administrator, shown in Figure 11.1. You can launch
Figure 11.1: You use the ColdFusion Administrator to control how the ColdFusion Server behaves.
Fusion Administrator either through the web interface (typically http://yourserver/ cfide/administrator/index.cfm) or through the Start â Programs menu (in Windows). You have access to nearly 30 categories of settings to control everything from how ColdFusion treats pages that are taking too long to process, to e-mail, to logging error messages and events. Although we certainly can't cover every feature of the ColdFusion Administrator in one chapter, we can explore those items that will immediately make your web application development even more enjoyable with ColdFusion.
Under the Settings category, you'll find a few general behaviors that don't quite fit into any other category. This category, however, controls a few important aspects of ColdFusion that can greatly affect your site visitor's experience with your application.
The Limit Simultaneous Requests setting controls how many requests your ColdFusion Server will process at any one moment. Let's suppose that you have just launched a web application that proves to be popular with the Internet community. As more and more people visit your site, it seems to get slower and slower, eventually bogging down to the point where even loading the home page takes forever. Well, until you move your application to a clustered server, you can try manipulating this setting so that your ColdFusion Server doesn't get hit with 100 simultaneous requests to load the home page at exactly the same moment.
This setting tells ColdFusion to handle only the number of requests you specify at any one moment. The rest of the folks have to wait in a queue until the server can get to them. This allows ColdFusion to respond rapidly to those that are in the immediate-process space so that it can then get to the other waiting users. You might need to experiment with this setting to find the optimal value; ColdFusion defaults to 10 requests. You'll have to stop and restart the ColdFusion Server in order for a change to this value to take effect.
This setting tells ColdFusion to watch over how long pages are taking to execute and stop them if they exceed the amount of time you specify. The default value, in seconds, is 60. Depending on your application, that may be more than enough time for any given procedure to run. Or, if your application performs intricate searching and logging of data, you might need to increase this setting.
The Timeout Requests setting helps keep your web server operating properly by canceling those pages that hang, for whatever reason. Perhaps a bug gets by you and causes your pages to never return a result to the user; the page simply loops and eats up your server's memory. With Timeout Requests enabled, you don't have to worry about that happening, since after 60 seconds, for instance, the page will simply stop and not crash the server.
This setting lets you specify a page that the server shows to the user instead of a 404 error if a page can't be found. Nothing is as inelegant as going to a professional website and receiving a 404, or Page Not Found, error. The ColdFusion Administrator let's you ensure that your site visitors will never receive a nasty-looking 404.
We've all received these errors. Perhaps we misspell a page name in a URL and receive something like the default Internet Explorer 404 error page shown in Figure 11.2, which doesn't give the user any information specific to the site. A well-behaved site will trap for these kinds of mistakes and show the user a page that is a bit more friendly. Our example in Figure 11.3, which isn't by any stretch of the word professional, at least doesn't show the cryptic error number to the user, and it includes links to other pages in the site. You might also include a phone number to call for technical assistance.
Figure 11.2: A 404, or Page Not Found, error is not an elegant way to handle a missing page error.
The Site-Wide Error Handler setting does the same thing as the Missing Template Handler for errors other than missing page errors. Again, it's always better to show a "controlled crash" error page to your user than an inelegant, standard system error page.
Figure 11.3: ColdFusion let's you specify a custom page that should be shown to the user when it can't find the page that was requested.
The Client Variables setting, shown in Figure 11.4, controls where ColdFusion Server stores client variables-variables that persist for clients across user sessions. The default setting, which we highly recommend you change, is to store this information in the system Registry. If you're running Windows, you know that this is a bad idea. You generally don't want variables stored in your system Registry. Not only will this cause Registry bloat, but it also slows down the system.
Figure 11.4: You should immediately set client variables to a data source instead of using the default of the system Registry.
Fortunately, ColdFusion Administrator allows you to store client variable information in a database, as well. You do have the option of storing client variables in cookies, but you have more control over the variables if you store them locally in a table. So create a data source and set the default storage to the table specified in the data source (see Chapter 4 for more information).
The Memory Variables setting lets you control how ColdFusion Server handles application and session variables. As you can see in Figure 11.5, you can specify the default timeout and the maximum timeout settings. The special control file, Application.cfm, can also control how long these variables exist on your server. However, the settings you specify here override the Application.cfm file. That's why you have a Maximum Timeout value. If your application states that an application variable should last for 7 days, but your server has a Maximum Timeout value of only 2 days, the variable will expire in 2 days.
Figure 11.5: You control how long ColdFusion Server stores memory variables through the Memory Variables setting.
This setting is especially useful in multi-application settings where many developers build applications. You can enforce server-setting policies through the ColdFusion Administrator since it always overrides Application.cfm.
Every Cold Fusion application can contain a special file named Application.cfm. This file is executed before every page in the application. ColdFusion looks first in the current page's directory for Application.cfm. If it doesn't find it, ColdFusion Server goes up one branch in the directory tree. It keeps searching until it finds an Application.cfm file.
Application.cfm is an optional file that is, in effect, automatically included at the top of every .cfm page that executes. Since ColdFusion looks in the current page's directory for the Application.cfm file, you can have more than one Application.cfm file per web application. Perhaps you need a set of variables to contain differing values depending on whether Sales or Marketing is using the system. You can set specific values for each department in an Application.cfm file for each folder (assuming, of course, that all Sales pages are in a Sales directory and all Marketing pages are in a Marketing directory).
Application.cfm is a regular .cfm file, and as such, can contain any ColdFusion code. Typically, Application.cfm is used to define default values for variables, data sources, application variables, and so forth. Login processing generally occurs in an Application.cfm file as well, since you can enforce a login check for every page.
The Settings Summary category creates a report of all your ColdFusion Server settings. Figure 11.6 shows a small section of a sample report. This report is a great aid in making sure your Cold- Fusion Server is configured the way you want it. It certainly beats clicking every category and then scrolling through the page to check settings. If only early versions of ColdFusion Server had provided such a tool.
Figure 11.6: The Settings Summary gives you a report that details every value for every setting in your ColdFusion Server.
The Data Sources category controls the data connections your ColdFusion Server is going to use. As you can see in Figure 11.7, you can connect to a number of database sources. And for those databases that aren't listed, you can probably use ODBC (Open Database Connectivity) as a connection protocol.
Figure 11.7: The Data Sources window lets you manage the data source connections used in your ColdFusion applications.
Every data source that your ColdFusion application is going to use must be defined in the Administrator before you can use it, since the CFQuery tag (more on that later) uses the data source name found here. (You can find more about database connections in Chapter 10.)
One of the best-loved tools developers find in ColdFusion is its debugger. The capabilities in the ColdFusion debugger allow you to see every piece of information you could hope for when it comes to debugging your programs. ColdFusion's debugger will automatically append debugging information to the end of your pages. You control most debugging settings in the Debugging Settings category, shown in Figure 11.8. Figure 11.8 shows the default debugging settings provided by ColdFusion. Let's look at some of those settings you might want to change.
Figure 11.8: The Debugging Settings category will become one of your favorite ColdFusion Administrator areas.
To enable debugging, you must select the Enable Debugging check box and click Submit Changes. When you do, each time you launch a .cfm page, you may see information like that in Figure 11.9, where we're debugging our "hello world" application. We say "may" because you actually must tell ColdFusion to show you the information. We'll cover how to do that shortly.
Figure 11.9: The debugging information you see may look similar to this.
You can display debugging information in two formats-classic and dockable. The classic format is shown in Figure 11.9. By simply scrolling through the page, you have immediate access to information such as the file that was running (Template), how long it took the page to execute (Execution Time), various variables, cookies, and more.
Figure 11.10 shows you a sample of the dockable format. By clicking the appropriate debug link in the main page, you can hide or show the debug window or dock it within the main page, as you can see in Figure 11.11.
Figure 11.10: You can display the debugging information in its own window.
Figure 11.11: Or you can dock the debugging information within a pane of the current page.
This debugging setting can be invaluable when trying to make your pages load faster or for trying to find where a breakdown in speed lies. Report Execution Times tells you how long it takes your page to execute, from start to finish, including load time. Pages that exceed the millisecond count you specify are highlighted in red in the data summary.
When it comes to debugging, you may find that there's no such thing as too much information. We recommend that you leave all the default settings in the Debugging Settings category, but also add the unchecked variables. That way, you can see every variable that could possibly affect your pages. Now, this is great if you're using the dockable debug window. If you're using the classic format, you may get tired of scrolling through all the information and want to uncheck the variable types you don't select that often.
We mentioned earlier that you actually need to tell ColdFusion to show you the debugging information when you've enabled the debugging option. You do that through the Debugging IP Addresses category. Figure 11.12 shows you the Debugging IP Address window, in which you enter the IP address of each computer for which you want to receive debugging information. If you have a team of developers, you can enter each of their specific IP addresses, and they'll see the debugging information for their pages. IPs that aren't listed here, perhaps the conference room computer, won't receive the debugging information.
Figure 11.12: To actually see the debugging information, you either enter a list of IP addresses or remove all the IP addresses.
Now, if you remove all the IP addresses from the list, every user receives the debug information. Be careful when changing this setting on your production, or live, servers. You don't want the world to see all the debugging information for your website. Not only is it embarrassing, but it could pose a big security risk!