cfset request.myvar #request.myvar# <-- fine <cfmodule template="foo.cfm"> <cinclude template="blah.cfm"> (in foo.cfm) #request.myvar# <-- fine (in blah.cfm) #request.myvar# <-- fine Also, no need to lock request scope reads and write because the cannot be accessed simulatneously by other sessions, page requests, of applications on the server. HTH, Paul. Nat Papovich ICQ 32676414 "If it was hard to write," says the Real Programmer, "it should be hard to understand." -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 10, 2000 1:16 PM To: Fusebox Cc: [EMAIL PROTECTED] Subject: RE: Idea? Well, Hal, as usual I just don't get it. Sorry. You earlier said: "It might be easiest to think of request variables as local variables that extend to any custom tags. They are unique to a user (just like a local variable) and they die with a new page request (just like a local variable). Because they are NOT shared scope variables, they don't need locking." But as I read the first two paragraphs quoted below I'm getting the impression that "global" as applied to Request scope means something different. Since even Allaire's printed CF4.5 docs don't list "Request" under Scope, it would help me if I had a concrete definition of what "global" means re: "Request scope" with concrete examples. Then I might not have to burden everyone with my examples. best, paul PS> Yes, I do "eschew session variables" Even better, having them in a database is a great step forward! All those complaints in Allaire's Forums years ago finally got thru.... ;-) At 01:44 PM 10/10/00 -0400, you wrote: >Since I introduced the problem, I'll try to finish the circle with the >solution. Again, there's nothing inherently wrong with global variables, as >long as the variables truly should be global. So a datasource would be a >good candidate for a global variable. A userID would also (tied to a session >or client), but something like "bookID" for a selected book would not -- >even if several files in a single http request need the info. In that case, >the variable should be set as an attributes style variable (which >FormURL2Attributes will do) and passed explicitly to any files that need it. > >If you do need global variables, you need to decide if you need persistence >as well. If you do, you can either use client variables or session, >application, or server variables (the latter three requiring CFLOCK). These >four variables all have persistence and global scope (limited global scope >in the case of client and session variables). An alternative to using them >(since I hate messing up my code with cflocks) is to use request scoped >variables that get set in app_globals, app_locals, myGlobals, >application.cfm -- or whatever method you use to ensure a page is run prior >to http requests. These don't require cflocks and in my very informal >metrics, the time associated with setting these is no greater than the time >to cflock and unlock the variable -- OK, it's a tiny bit longer, but we're >talking miniscule amounts here. > >If you're still with me, the one final consideration is this: will your >application now or at any time in the future be in a clustered environment? >If so, eschew session variables and use client variables. Yes, there are >sticky sessions that get around the problem, but they do so at the expense >of much of the benefits of clustered environment. ---------------------------------------------------------------------------- -- To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. ------------------------------------------------------------------------------ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
