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.
Nat was right in saying that global variables are dangerous. There's nothing
wrong with using them where they make sense -- but often they are used
poorly and so experienced coders tend to be a little antsy when they hear
the term "global". My suggested use of the request scope instead of the
attributes scope was a poor use for them. Good uses for global variables
would be constants and semi-constants. Things like datasources, mappings (if
you use mappings like "imageRoot" or "appRoot") -- things that truly should
be guaranteed to be the same for all nooks and crannies of an application.
The reason my idea was a bad one was that there are lots of attributes set
and almost none of them should be global in scope.
Ah, laziness makes a man do wild and crazy things.
-----Original Message-----
From: paul smith [mailto:[EMAIL PROTECTED]]
Sent: Sunday, October 08, 2000 3:26 PM
To: Fusebox
Subject: RE: Idea?
So if they're that dangerous, when are they NOT dangerous?
best, paul
At 03:03 PM 10/8/00 -0400, you wrote:
>Because request is friggin global in scope! That is mucho dangerous. I
would
>NEVER think that you of all people, Hal, would be an advocate of such
global
>variables (much less come up with the idea yourself). On my current
project,
>we've decided to extremely limit the use of request scope, because there is
>just too much chance of stepping on other code and whacking out variables.
I
>mean, who knows what that custom tag you wrote last year uses for it's
>variable names! I know that custom tags don't usually mess with request
>scope, but nonetheless, it's too dangerous.
----------------------------------------------------------------------------
--
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.
