I certainly agree with you in principle that global variables are very
dangerous. But I was thinking that within a single http request, they might
be OK...
Yep, you're right. It's a bad idea. In fact, it's a spectaculary bad idea. I
shall now turn unplug my keyboard for 5 minutes in penance for having lost
my way...no, it was just an idea which is kinda more like a temptation than
an actual act...maybe 2 minutes would suffice.
-----Original Message-----
From: Nat Papovich [mailto:[EMAIL PROTECTED]]
Sent: Sunday, October 08, 2000 2:43 PM
To: Fusebox
Subject: RE: Idea?
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.
Other than the encapsulation and lack of coupling issues, go for it. Those
reasons are enough for me to think that the request scope is to be treated
very carefully, not scoping everything available into it, willy-nilly.
Nat Papovich
ICQ 32676414
"If it was hard to write,"
says the Real Programmer,
"it should be hard to understand."
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Sent: Sunday, October 08, 2000 11:32 AM
To: Fusebox
Subject: Idea?
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C03134.820A2FE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Right now, we turn all form and URL variables into attributes variables. Now
that we have the request scope (which wasn't available when Steve and Gabe
did the original spec), can anyone think of a good reason not to turn them
into request-scoped variables instead? It would still work with either
<cfinclude> or <cfmodule>.
The reason I'm thinking about this is that while I'm developing, I use a
custom tag called "LogTest" that helps me track what's happening internally
by writing stuff to a log file. One thing I want to log is the fuseaction
name, but if I'm calling this from a custom tag (say as a function), then
the fuseaction isn't available to me unless I explicitly pass it in. I'd
rather not have to do this. I can't think of a reason not to turn these into
request variables, but I might be missing something.
Hal
------=_NextPart_000_000B_01C03134.820A2FE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D790372518-08102000>Right =
now, we turn=20
all form and URL variables into attributes variables. Now that we have =
the=20
request scope (which wasn't available when Steve and Gabe did the =
original=20
spec), can anyone think of a good reason not to turn them into =
request-scoped=20
variables instead? It would still work with either <cfinclude> or=20
<cfmodule>. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D790372518-08102000></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D790372518-08102000>The =
reason I'm=20
thinking about this is that while I'm developing, I use a custom tag =
called=20
"LogTest" that helps me track what's happening internally by writing =
stuff to a=20
log file. One thing I want to log is the fuseaction name, but if I'm =
calling=20
this from a custom tag (say as a function), then the fuseaction isn't =
available=20
to me unless I explicitly pass it in. I'd rather not have to do =
this. I=20
can't think of a reason not to turn these into request variables, but I =
might be=20
missing something.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D790372518-08102000></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D790372518-08102000>Hal</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D790372518-08102000></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D790372518-08102000></SPAN></FONT> </DIV></BODY></HTML>
------=_NextPart_000_000B_01C03134.820A2FE0--
----------------------------------------------------------------------------
--
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.
------------------------------------------------------------------------------
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.
