I think the real problem with using request scope variables for everything (other than not having ANY local attributes) is that your user could do harmful things like changing the datasource of your queries, or a really scary one is the account of a bank that credit card transactions go to. i.e. if all form and URL variables were request you could call this URL: http://www.domain.com/index.cfm?maindsn=otherdsn&account=123456 <cfquery name="myquery" datasource="#request.maindsn#"> ... </cfquery> or <!---- credit card transaction ----> <cf_authorizenet account="#request.account#" ....> You want some variables available to the end user (i.e. through URL, form or cookies), but you want other variables only available to the programmer. See what I mean? Steve Hal Helms wrote: > > 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.
