Since I introduced the problem, I'll try to finish the circle with the solution. Again, there's nothing inherently wrong with global variables, as long as the variables truly should be global. So a datasource would be a good candidate for a global variable. A userID would also (tied to a session or client), but something like "bookID" for a selected book would not -- even if several files in a single http request need the info. In that case, the variable should be set as an attributes style variable (which FormURL2Attributes will do) and passed explicitly to any files that need it. If you do need global variables, you need to decide if you need persistence as well. If you do, you can either use client variables or session, application, or server variables (the latter three requiring CFLOCK). These four variables all have persistence and global scope (limited global scope in the case of client and session variables). An alternative to using them (since I hate messing up my code with cflocks) is to use request scoped variables that get set in app_globals, app_locals, myGlobals, application.cfm -- or whatever method you use to ensure a page is run prior to http requests. These don't require cflocks and in my very informal metrics, the time associated with setting these is no greater than the time to cflock and unlock the variable -- OK, it's a tiny bit longer, but we're talking miniscule amounts here. If you're still with me, the one final consideration is this: will your application now or at any time in the future be in a clustered environment? If so, eschew session variables and use client variables. Yes, there are sticky sessions that get around the problem, but they do so at the expense of much of the benefits of clustered environment. -----Original Message----- From: paul smith [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 10, 2000 1:19 PM To: Fusebox Subject: RE: Idea? 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. ------------------------------------------------------------------------------ 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.
