I agree and disagree with you. First off, query string variables have a certain level of unreliability. You would not want to pass sensitive information in the query string or values, that if changed, would cause negative results or undesired results. Secondly, it is the coders responsibility to take into account a visitor changing the query string, and thus accomidating a change.
I don't agree with just resorting to the session scope either. I am guilty of this in the past, but have found that making use of the request scope has proven to be a much more efficient way in that you cut down on locking and the such. Use sessions, but copy the session scoped vars to the request scope and lock once (application.cfm would be a good place for this). Also, I would not "set" the variable variables.AppendToQueryString equal to noQS for the simple reason that if you set this variable to something else in a subsequent page then make a new request, that variable gets "set" to noQS again (because application.cfm executes before any other page)... meaning you never get the variable where you want it anyway. I could be way off base, but I would rethink what you are trying to pass around the application and the manner by which you are doing it... see if you can better organize the way information needs to be passed and really solve the root of the problem and not "fix" it... it will creep back up on you down the road. If I am missing what you are saying, post back... Mike -----Original Message----- From: Costas Piliotis [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 2:20 PM To: CF-Talk Subject: RE: query string variable idea Uhm... There's some problems inherent with using url strings to control your variables. First. Why would you want to use a URL variable instead of a session variable? In application.cfm, you could just add: <cfif isDefined("url.varname"> <cflock scope="SESSION" timeout="10"> <cfset session.varname = url.varname> </cflock> </cfif> Then use session.varname as you see fit. Second. Querystring variables are inherently bad to use for anything that's important. They are only really useful for saving searches. Anything that's even remotely critical is best handled through POST variables or COOKIES... Third. Querystring variables are limited to one dimension values. Sessions can store arrays. Forth. Querystrings, until IE 5.5, were limited to 255 characters. This limits the amount of variables you can have in a url unless you limit browsers to IE 5.5 or better. I have no idea why you would want to do what you are saying... Perhaps you could enlighten me as to why and perhaps more people would understand... -----Original Message----- From: Cornillon, Matthieu [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 9:35 AM To: CF-Talk Subject: query string variable idea Hi, there. In trying to solve a problem this weekend, it occurred to me that I could easily handle my situation by passing a particular URL variable with every link on my site. Unfortunately, that would mean going through and appending that URL variable to every link on my site, so I ended up going with a different solution. But then it occurred to me that I might be onto an idea for a future project. Why not set up my site so that every link on the site has the local variable AppendToQueryString added to it. So, every link would look like this: <a href=" http://www.mysite.com/subdir/file.cfm#Variables.AppendToQueryString <http://www.mysite.com/subdir/file.cfm#Variables.AppendToQueryString> #"> In the Application.cfm, I set Variables.AppendToQueryString equal to ?noQS. That way, any time that I want to solve a problem by adding a particular query string variable, I can just add it on to Variables.AppendToQueryString in the appropriate page. I can also add things across the site by changing the default value in Application.cfm. This is all hypothetical: for now, I have no need for it. But I was wondering whether taking this infrastructure step is problematic for some reason, or if there is some established better way of doing it. Any thoughts? Thanks, Matthieu ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
