Well, now that we've soundly flogged the presenter and the *problem*, what's the *solution* that has most of the Request scope advantages (for example, Request scoped vars don't require CFLOCKing) but not its "global dis-advantage"? Scope local variables & cached queries with the Attributes scope? Give up and go to Application/Session/Client variables and CFLOCK down everything that moves? Switch to PHP? (evil grin) best, paul At 08:58 AM 10/9/00 -0400, you wrote: >Yep. Good point, Steve. > >I think we should have an annual award for "Outstanding Accomplishment in >Coming Up with a Truly Lame Idea". And though it may seem immodest to do so, >I nominate myself for this prestigious, first-ever award. > >-----Original Message----- >From: Steve Nelson [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 09, 2000 7:13 AM >To: Fusebox >Subject: Re: Idea? > > >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 > > ------------------------------------------------------------------------------ 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.
