ouch man, you wanna go kick his dog too? :) -----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.
