Creating APPLICATION Variables


Creating APPLICATION Variables

If you plan to use APPLICATION variables, each page of your Web site must belong to a specific application. Coding this information on each individual page can be time-intensive and a maintenance headache. Therefore, the Application pages are the perfect location to put this information.

Application pages was discussed in Chapter 6, "The Application Framework."


To use APPLICATION variables the application must be named (as seen in Chapter 6).

CAUTION

Be careful when naming your application. If you give the same name to two different applications on the same server, the server will treat them as if they were the same application and will allow one to see the other's APPLICATION variables.


TIP

On the converse of that caution, you can use the naming of your application to your advantage. If the framework of your application requires that you put associated files in widely separated directories, you can still treat the files as part of the same application by naming them accordingly.


Creating APPLICATION variables is very similar to creating local variables. The only addition required is the proper scope, as shown here:

 <cfset APPLICATION.FName="Emily"> 

This code creates a variable called FName with a value of Emily and places it in the APPLICATION scope. Now it can be used everywhere in your application until it hits its time limit.

Complex data can also be stored in APPLICATION variables. In the following code, the query is created as normal but placed into the APPLICATION scope by prefixing it:

 <cfquery name="APPLICATION.GetStates"          datasource="Employees"> SELECT StateAbbreviation, StateName FROM States </cfquery> 

Now the query result set will be available in memory. You can use the query as usual, but with the addition of the scope as shown here:

 <cfoutput query="APPLICATION.GetStates"> #StateAbbreviation# #StateName#<br> </cfoutput> 

CAUTION

APPLICATION variables are great places to store some query record sets, but others should not be placed in them. For instance, personalized user information should not be stored in APPLICATION variables. Because APPLICATION variables are available to the entire application, they apply to all users. Personalized information is better stored in COOKIE, CLIENT, or SESSION variables.


COOKIE, CLIENT, and SESSION variables are discussed in Chapter 11, "Session State Management."


Because APPLICATION variables stay in memory for the specified period of time, it doesn't make sense for you to run the query against the database every time the page is accessed. You should run the query only if it has expired in memory.

If using Application.cfc, use the onApplicationStart() method to ensure that APPLICATION variables are not reinitialized unnecessarily. If using Application.cfm, a conditional statement is placed around the query (as seen in this example):

 <cfif not IsDefined("APPLICATION.GetStates")>  <cfquery name="APPLICATION.GetStates"           datasource="Employees">  SELECT *  FROM States  </cfquery> </cfif> 

<cfif> was discussed in Chapter 3, "Conditional Processing."


CAUTION

APPLICATION variables persist on the server for a given length of time and are not refreshed until their time limit has been reached. Therefore, if you need to refresh the APPLICATION variables, you must do so programmatically using conditional processing.


TIP

Checking for the existence of APPLICATION variables before you use them is always a good idea. Not only do they expire naturally, but they also are lost if the server is ever rebooted.




Macromedia ColdFusion MX 7 Certified Developer Study Guide
Macromedia ColdFusion MX 7 Certified Developer Study Guide
ISBN: 0321330110
EAN: 2147483647
Year: 2004
Pages: 389
Authors: Ben Forta

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net