Dawn, Application scope is a perfectly good place to store your datasource and an AdminEmail. You will want to set up some logic so that you are only setting those variables one time (on application startup), such as in application.cfc or .cfm. It is a best practice to use a CFLOCK when writing to the application scope. We could probably start a whole other thread on whether or not you need to use the CFLOCK to READ your application variable, but my preference is that it is not necessary. Especially when you are only setting the value on application startup. There is a school of thought out there that you should lock all application scoped varaibles ANY time you read or write to them. As a result, oftentimes, developers will duplicate the application scope into the request scope (meaning that this happens on every page request) so that you could reference the same values without having to use a CFLOCK (since there is no argument that you don't need to CFLOCK Request scoped variables). In any case, I think it's just fine to store those variables in your application scope and access them throughout your application (for reading purposes) without a CFLOCK. I'm sure there are some on this list who might share the alternate viewpoint better than me since I don't agree with it, but more power to them if they want to. Sincerely, Dave Phillips President WebTech Staffing, LLC <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Green, Ms. Dawn Sent: Thursday, May 10, 2007 4:19 PM To: Dallas/Fort Worth ColdFusion User Group Mailing List Subject: RE: [DFW CFUG] Application Variables I use the book that Ben Forta and Ray Camden (ColdFusion MX 7) did and in the examples of their Application.cfc pages they always set the datasource as a request variable. I had done some reading and I didn't understand why you would set them up as a request variable versus the application variable. The reason this came up is that my department is developing a site on our server. This new site will eventually be moved to another server with a different name. So I thought we would be smart and declare the root address of the site as a request variable on the application.cfc page. This worked until someone's session would timeout and it would take them back to the login page. When this would happen the images showed up as broken images. It is like the request variables were no longer there. So I then had to do additional code on the login page to redeclare the Request variable. I had hoped to declare this once for ease of changing when we moved the site. This made me think. I wonder why you couldn't just use an application variable? And If I did, then why not use the datasource name and the adminEmail address as an application variable too? I did some reading up on it and from what I got out of it was "Use application variables when you know they won't change". We have only 1 datasource and it won't change. We will only have 1 adminEmail and it won't change while the application is running. And once the site is moved to its new home, It won't change. So I guess my question is. Will this fix my broken images tags when the session is timed out and the user is forced back to the login page? Is this a good idea in this circumstance? What would be the pros and cons of its use in this instance? HELP!!! Dawn From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Green, Ms. Dawn Sent: Thursday, May 10, 2007 2:11 PM To: [email protected] Subject: [DFW CFUG] Application Variables In an application.cfc page, why would you use request variables to set your datasource, rootname of your site & adminEmail instead of Application variables? What are the pros and cons of doing it either way? Thanks for any help in clarifying this for me. Dawn Green
_______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.instantspot.com/ www.teksystems.com/
