Application variables

I've been on http://www.benorama.com looking at a CF design pattern. In this tutorial it talks about using your Application.cfm to call _init.cfm, which parses through an xml file to create your application variables. I've done this (very closely following the sample app). I've created a page using cfdump to show me the application variables, but when I change my xml doc and refresh my page the application variables do not appear to update? Any ideas? Cutter

You have to restart CF to reset APPLICATION vars (timing out the app might work too). Personally I like to use REQUEST scope over APPLICATION scope ;-) Bryan Stevenson B.Comm. VP & Director of E-Commerce Development Electric Edge Systems Group Inc. t. 250.920.8830 e. bryan@electricedgesystems.com --------------------------------------------------------- Macromedia Associate Partner www.macromedia.com --------------------------------------------------------- Vancouver Island ColdFusion Users Group Founder & Director www.cfug-vancouverisland.com ----- Excess quoted text cut - see Original Post for more -----

Bryan Stevenson wrote: > You have to restart CF to reset APPLICATION vars (timing out the app might > work too). application=strucnew(); z

You can overwrite them with <cfset> ... though I typically use <cfset request.myapp.myvar = "something"> instead of application variables for this sort of thing also. The app could be using <cfparam> tags instead of <cfset> tags in which case it would chew through the xml file on each request unecessarily since the param won't overwrite the existing value. Or it could use something like <cfif not structkeyexists(application,"init")> to determine when to load the application vars, in which case, it won't reload them when you modify the xml file because application.init already exists. You could use a url variable to force the app to reload the xml file in this situation, however, which wouldn't be too tough to accomplish or too hard on the server... <cfparam name="url.init" type="boolean" default="#yesnoformat(not structkeyexists(application,"init"))#"> <cfif url.init>   ... chew up the xml file here ... </cfif> Then when you update the xml file, just load the application's default page with &init=true in the query string ----- Excess quoted text cut - see Original Post for more -----

What's are the Pro's and Con's  of using Request Variables over Application Var? You can overwrite them with <cfset> ... though I typically use <cfset request.myapp.myvar = "something"> instead of application variables for this sort of thing also. The app could be using <cfparam> tags instead of <cfset> tags in which case it would chew through the xml file on each request unecessarily since the param won't overwrite the existing value. Or it could use something like <cfif not structkeyexists(application,"init")> to determine when to load the application vars, in which case, it won't reload them when you modify the xml file because application.init already exists. You could use a url variable to force the app to reload the xml file in this situation, however, which wouldn't be too tough to accomplish or too hard on the server... <cfparam name="url.init" type="boolean" default="#yesnoformat(not structkeyexists(application,"init"))#"> <cfif url.init>   ... chew up the xml file here ... </cfif> Then when you update the xml file, just load the application's default page with &init=true in the query string ----- Excess quoted text cut - see Original Post for more -----

Well a big plus is that you don't need to lock REQUEST scoped vars. Bryan Stevenson B.Comm. VP & Director of E-Commerce Development Electric Edge Systems Group Inc. t. 250.920.8830 e. bryan@electricedgesystems.com --------------------------------------------------------- Macromedia Associate Partner www.macromedia.com --------------------------------------------------------- Vancouver Island ColdFusion Users Group Founder & Director www.cfug-vancouverisland.com > What's are the Pro's and Con's  of using Request Variables over Application > Var? > > You can overwrite them with <cfset> ... though I typically use <cfset > request.myapp.myvar = "something"> instead of application variables for this > sort of thing also. The app could be using <cfparam> tags instead of <cfset> ----- Excess quoted text cut - see Original Post for more ----- however, ----- Excess quoted text cut - see Original Post for more ----- page > with &init=true in the query string > > > You have to restart CF to reset APPLICATION vars (timing out the app might ----- Excess quoted text cut - see Original Post for more -----

Depending on how you use them, in cfmx you don't need to lock application vars as well. ======================================================================= Raymond Camden, ColdFusion Jedi Master for Hire Email    : ray@camdenfamily.com WWW      : www.camdenfamily.com/morpheus Yahoo IM : morpheus "My ally is the Force, and a powerful ally it is." - Yoda ----- Excess quoted text cut - see Original Post for more -----

Do you have to set them each time, for each page? Well a big plus is that you don't need to lock REQUEST scoped vars. Bryan Stevenson B.Comm. VP & Director of E-Commerce Development Electric Edge Systems Group Inc. t. 250.920.8830 e. bryan@electricedgesystems.com --------------------------------------------------------- Macromedia Associate Partner www.macromedia.com --------------------------------------------------------- Vancouver Island ColdFusion Users Group Founder & Director www.cfug-vancouverisland.com > What's are the Pro's and Con's  of using Request Variables over Application > Var? > > You can overwrite them with <cfset> ... though I typically use <cfset > request.myapp.myvar = "something"> instead of application variables for this > sort of thing also. The app could be using <cfparam> tags instead of <cfset> ----- Excess quoted text cut - see Original Post for more ----- however, ----- Excess quoted text cut - see Original Post for more ----- page > with &init=true in the query string > > > You have to restart CF to reset APPLICATION vars (timing out the app might ----- Excess quoted text cut - see Original Post for more -----

Nope.  I will generally test for the existence of one of my REQUEST vars in Application.cfm.  If it doesn't exist I assume none of them are set and I use CFPARAM to set them all.  Once set they won't be reset on every page. If I ever need to reset them, I just comment out the CFIF that checks for the existence of one of them and re-save the file and hit any page in the system. HTH Bryan Stevenson B.Comm. VP & Director of E-Commerce Development Electric Edge Systems Group Inc. t. 250.920.8830 e. bryan@electricedgesystems.com --------------------------------------------------------- Macromedia Associate Partner www.macromedia.com --------------------------------------------------------- Vancouver Island ColdFusion Users Group Founder & Director www.cfug-vancouverisland.com ----- Excess quoted text cut - see Original Post for more ----- the ----- Excess quoted text cut - see Original Post for more ----- In ----- Excess quoted text cut - see Original Post for more ----- application > > >> variables. I've done this (very closely following the sample app). I've ----- Excess quoted text cut - see Original Post for more ----- variables ----- Excess quoted text cut - see Original Post for more -----

  I believe you are mixing up request and application variables.   If the application.cfm is running, then it is safe to assume that this is a new page request, and request variables have not been defined yet (unless they were defined earlier in the Application.cfm )   Additionally, if you feel safe assuming that if the one you check for is not set, then none are not set, use cfset ( or even better CFSCript) to set the variables.  This will allow you to avoid the extra overhead with cfparam. At 11:09 AM 11/25/2002 -0800, you wrote: ----- Excess quoted text cut - see Original Post for more -----

  Request variables and Application variables are two completely different things, so i don't know if they deserve direct comparison.  It depends what you want to use them for.   Request variables exist during a single page execution.   They are not persistent across page requests.   You do not need to lock them.   If 100 users hit the same page at once, then 100 instances of each request variable will exist simultaneously.   Request variables are available to all templates in the request, including custom tags.  Because of this, I like to say that they are global to the request.  Many people use them to avoid passing parameters into custom tags.  I feel that is the only use for them over local variables (I.E. the variables scope ).   Application variables are locked into an application via the cfapplication tag.   They are persistent across page requests.   You really should lock them.    If 100 users hit the same page at once, then only 1 copy of each application variable will exist.    They are available to all templates in the request, including custom tags.    Does that give you enough to go on? At 10:40 AM 11/25/2002 -0800, you wrote: ----- Excess quoted text cut - see Original Post for more ----- -- Jeffry Houser | mailto:jeff@farcryfly.com DotComIt, Putting you on the web AIM: Reboog711  | Phone: 1-203-379-0773 -- My CFMX Book: <http://www.amazon.com/exec/obidos/ASIN/0072225564/instantcoldfu-20>; My Books: http://www.instantcoldfusion.com My Band: http://www.farcryfly.com

So, it seems to me that in a purist sense, common values across all Users belong in application variables.   Request variables and Application variables are two completely different things, so i don't know if they deserve direct comparison.  It depends what you want to use them for.   Request variables exist during a single page execution.   They are not persistent across page requests.   You do not need to lock them.   If 100 users hit the same page at once, then 100 instances of each request variable will exist simultaneously.   Request variables are available to all templates in the request, including custom tags.  Because of this, I like to say that they are global to the request.  Many people use them to avoid passing parameters into custom tags.  I feel that is the only use for them over local variables (I.E. the variables scope ).   Application variables are locked into an application via the cfapplication tag.   They are persistent across page requests.   You really should lock them.    If 100 users hit the same page at once, then only 1 copy of each application variable will exist.    They are available to all templates in the request, including custom tags.    Does that give you enough to go on? At 10:40 AM 11/25/2002 -0800, you wrote: ----- Excess quoted text cut - see Original Post for more ----- -- Jeffry Houser | mailto:jeff@farcryfly.com DotComIt, Putting you on the web AIM: Reboog711  | Phone: 1-203-379-0773 -- My CFMX Book: <http://www.amazon.com/exec/obidos/ASIN/0072225564/instantcoldfu-20>; My Books: http://www.instantcoldfusion.com My Band: http://www.farcryfly.com

  I would agree.  At a conceptual level.  If a variable is being used a lot, however, it may make not make sense to store it in a local (or request) variable to avoid the need for locks.   Of course, that was in CF5.  I don't know of best practices for CFMX yet. At 01:08 PM 11/25/2002 -0600, you wrote: ----- Excess quoted text cut - see Original Post for more -----

On Monday 25 Nov 2002 20:02 pm, you said: >   I would agree.  At a conceptual level.  If a variable is being used a > lot, however, it may make not make sense to store it in a local (or > request) variable to avoid the need for locks. > >   Of course, that was in CF5.  I don't know of best practices for CFMX yet. Do a request.application = duplicate(application) inside a lock in the application.cfm ? -- Thomas C "Does google know ?"

And this doesn't suffer from the confusion of race conditions either since you can't have a race condition caused by a request var. ----- Excess quoted text cut - see Original Post for more ----- s. isaac dealey                954-776-0046 new epoch                      http://www.turnkey.to lead architect, tapestry cms   http://products.turnkey.to certified advanced coldfusion 5 developer http://www.macromedia.com/v1/handlers/index.cfm?ID=21816

Yea, you'd just use something like this in your application.cfm template: <cfset request.myapp.dsn = "mydsn"> <cfset request.myapp.mailserver = "mail.mydomain.com"> <cfset request.myapp.url_login = "https://www.mydomain.com/securelogin/index.cfm">; etc... ----- Excess quoted text cut - see Original Post for more ----- s. isaac dealey                954-776-0046 new epoch                      http://www.turnkey.to lead architect, tapestry cms   http://products.turnkey.to certified advanced coldfusion 5 developer http://www.macromedia.com/v1/handlers/index.cfm?ID=21816

> Bryan Stevenson wrote: >> You have to restart CF to reset APPLICATION vars (timing >> out the app might >> work too). > application=strucnew(); I'm not necessarily convinced that would clear the application scope rather than creating a local variable called application. structclear(application); might be better. s. isaac dealey                954-776-0046 new epoch                      http://www.turnkey.to lead architect, tapestry cms   http://products.turnkey.to certified advanced coldfusion 5 developer http://www.macromedia.com/v1/handlers/index.cfm?ID=21816

wasn't my idea ;-) Bryan Stevenson B.Comm. VP & Director of E-Commerce Development Electric Edge Systems Group Inc. t. 250.920.8830 e. bryan@electricedgesystems.com --------------------------------------------------------- Macromedia Associate Partner www.macromedia.com --------------------------------------------------------- Vancouver Island ColdFusion Users Group Founder & Director www.cfug-vancouverisland.com ----- Excess quoted text cut - see Original Post for more ----- rather ----- Excess quoted text cut - see Original Post for more -----

Storing variables in the application scope allows you to temporarily change application-wide settings, which can be useful at times, for instance, if you had an application which required scheduled maintenance to take several minutes ( or hours or however long ), it's possible you might want to log all users out or at least just preven them from making updates which might interfere with the maintenance, in which case, you would want to use something like this <cfparam   name="application.maintenanceperiod"   type="boolean" default="false" /> in your application.cfm template -- then in the template for your scheduled task to perform maintenance, you would use <cfset application.maintenanceperiod = true />   ... do maintenance here ... <cfset application.maintenanceperiod = false /> On CF 5 you would want to lock references to your application.maintenanceperiod variable, however, the viability of this as a means of isolating the maintenance routine is still good in either CF 5 or CF MX. On the other hand, I would tend to avoid placing variables like datasource names, server addresses ( mail server for instance ) and url's in the application scope because these variables change rarely and usually not for short periods of time, so imo placing them in the application scope is an unnecessary use of persistent memory and it's best to just declare them in the application.cfm or the like and then update that template when changes are necessary. I'm not saying this is "best case" or anything -- just my opinions about it. s. isaac dealey                954-776-0046 new epoch                      http://www.turnkey.to lead architect, tapestry cms   http://products.turnkey.to certified advanced coldfusion 5 developer http://www.macromedia.com/v1/handlers/index.cfm?ID=21816 ----- Excess quoted text cut - see Original Post for more -----