Can someone expand on why this would be a bad idea? I converted the
formurl2attributes to formurl2request some time ago and have found it works
wonderfully ... it simplified things even further in coding. I run on a common sense
mode most of the time and that seemed like a very sensible way of standardizing a
scope to work in. Like hal mentioned ... it's a single http request ... I'm sorry, I
don't see why it's a bad idea?!
---------- Original Message ----------------------------------
From: "Hal Helms" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: Sun, 8 Oct 2000 15:03:44 -0400
>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.
>
------------------------------------------------------------------------------
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.
