Thanks so much for your time and input, too, Ben! Everyone's help has been invaluable!
While I took a break for a cup of coffee, I reflected on what it was like before the Internet, email and mailing lists came along. I remember waiting weeks for responses to snail mail requests for information. Or trying to happen up an article in a magazine that addressed an issue. I'm sure it would be amazing to know how much access to information throught the Internet, email, forums, etc., has increased productivity and made possible so many things that otherwise could not have been done. Experts at your fingertips... It always makes me so grateful when I'm helped and I remember that when I see others in places seeking info that I have and help when I can. Thanks everyone! Rick -----Original Message----- From: Ben Doom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 11:23 AM To: CF-Talk Subject: RE: One dynamic site for multiple indepentdent businesses : 1) If the Name of my CFAPPLICATION is the same for each business, : then I risk users overwriting each other's variables. Only if you are storing data there that shouldn't be stored there. The application scope is intended for use for storing variables that are common to every instance of an application. Storing data there in the way you described is basically a misuse of the application scope. : 2) If I use a unique, dynamic Name for each CFAPPLICATION when : a person enters the site, then I can use Application Scope variables : without them being overwritten with 2 or more users on the site : concurrently? Yes, although I think what was suggested is that you create a different application name not for each request or user but rather for each different set of data, ie for each domain. : Does having a unique Name for the CFAPPLICATION affect the names : of Application variables behind the scenes? Or do the two have : anything to do with each other? Nope. You define the name of the application once in the cfapplication tag. This is simply to allow you to differentiate between applications. After that, you use the standard application.variable calls and they should work just fine. That is, application "bob" and application "sam" can both have application variables named "var", but application.var called in the bob application will never reference the application.var in the sam application and vice versa. : 3) Even if statement 2 is true, change all application variables : to request : variables : for use throughout the site? I would, simply to avoid locking issues. Remember, locking slows your application down. : Concerning Session, Application, and Request scope variables: : : 1) Application variable access are not specific to a particular user's : session on the site? Correct. They are specific to (surprise!) an application. : And, therefore, a specific variable *can* be overwritten by different : users within other users' sessions? Yes. So don't do that. :-) : 2) Session and Request variables are specific to a particular user's : session on the site? Yes and no. Session variables are specific to a session (they are referenced by checking cookies or url tokens and persist until they are deleted or time out). Request variables are specific to a single page request. They persist from creation until the page has finished processing and is served. Then they dissapear. They differ from variable scoped variables (how's that for redundancy?) AFAIK in that request scoped variables are accessible from custom tags. : And, therefore, a specific Session or Request variable *cannot* be : overwritten by different users within other users' sessions? Correct. : Concerning Locking: : : 1) Application variable need to be locked. Yup. Since multiple requests can read/write, you have to make sure that no one is reading an incomplete write, or trying to write then read while another request is trying to change the values, etc. : 2) Request variables do not. Never have to lock these as they are specific to a request and therefore aren't shared. : 3) What about Session variables? Always. If there are two simultaneous requests from a single session, you see the same problems as with application variables if you don't lock them. : I've done some reading on the scope variables, but haven't found the : explanation : of the kinds of aspects we're discussing. (Perhaps I just haven't looked : hard enough) : If you can tell me where to find a good explanation of these things, then : perhaps : I wouldn't have to have you spoon feed me so much! I am rereading the : documentation : on scope variables, now that I need deeper understanding. : Perhaps there are : some : other good articles/resources for understanding you know of? I got most of this from the CF5 Certification study guide. I had some help understanding client variables from the list. : I like your idea below...it puts some framework behind what I'm trying to : do. : : When the Request variables are setup, I won't define every piece of : information : for the site at that time, in order to keep things moving. I figured I'd : wait to : define, for instance the BusinessAddress, with a query with the BusinessID : was : the relational key, until it was needed for the "Contact Us" page. : Any particular reason why it would be better to define everything up front : on the : Application.cfm that's needed, or does it matter? 6 of one, half : a dozen of : the other? This is a question of people time vs computer time. What you suggest is more efficient (assuming you never repeat a query, don't use multiple queries where one would do, etc). However, grabbing everything you might need right up front means you as a programmer don't have to do so much work keeping track of what's already been called, etc. Also, as you make changes to the app, you always know what's available to the application without having to check and see if you've already grabbed that data or not. This is a personal call as to style. I know what I prefer, but others might (and likely would) disagree. : Thanks for your insights...they are much appreciated. : I've had some personal emails sent to me about this thread where : people have stated they have been considering doing the same sort of thing : and have enjoyed and learned from the discussion... I've worked on something similar recently. I like the Keith's idea of multiple application names. I'm sure I've gained something out of this, if only by forcing myself to think about scopes in a more expressable way. :-) --Ben Doom Programmer & General Lackey Moonbow Software ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
