Actually it does put it in the scope. It works fine using APPLICATION instead of REQUEST. And the variables do seem to exist for a split second, because I include the below code into the application.cfm, and then the CFAPPLICATION uses request.applicationName, which comes out of the WDDX file. But any files after the application.cfm, the request scoped variables no longer exist.
And yes, if I use request.something, it does all work fine, and that is what I am doing for now, but I would like to know why it doesn't work just as REQUEST. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: 10 May 2004 14:14 > To: [EMAIL PROTECTED] > Subject: Re: [ cf-dev ] Copy application scope to request scope > > > > output="request"> > > This says, store the output in a variable called request. It > doesn't store it in the Request scope. Possibly if you > tried: output="Request.somevar"> that might work > > > > > > > "Snake > > Hollywood" To: > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED] cc: > > kepit.net> Subject: [ > cf-dev ] Copy application scope to request scope > > > 10/05/2004 14:08 > > Please respond > > to dev > > > > > > > > > OK I am just sick and tired of looking at this now, don't > have the energy for debugging these days, having kids really > takes it out of you :-) > > I store all my global_variables in a WDDX file, which I read > in and store in a request variable, then convert the WDDX > into structures in REQUEST scope. > > Here is the code > > --- > > <cfset request.encryptKey = ""><!--- the > encryption key if used onthe wddx file ---> > <cfsavecontent variable="request.config"><cfinclude > template="global_variables.wddx"></cfsavecontent> > > <cfif request.encryptkey IS ""> > <!--- don't decrypt if no encryptkey > provided ---> > <cfwddx action="WDDX2CFML" > input="#request.config#" output="request"> > <cfelse> > <!--- decrypt wddx packet ---> > <cfwddx action="WDDX2CFML" input=" > #Decrypt(request.config, requestencryptkey)#" output="request"> > </cfif> > --- > > > Now for some reason the structures never seem to get created. > But doing a CFDUMP of request scope, does show request.config > is there, and does actually show all it's internal > structures. The CFWDDX code definitely gets run, but is not > producing anything. > > Any ideas.?? > > > > Russ > > > > > -- > These lists are syncronised with the CFDeveloper forum at > http://forum.cfdeveloper.co.uk/ > Archive: > http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > CFDeveloper Sponsors and contributors:- > *Hosting and support provided by CFMXhosting.co.uk* :: > *ActivePDF provided by activepdf.com* > *Forums provided by fusetalk.com* :: *ProWorkFlow provided by > proworkflow.com* > *Tutorials provided by helmguru.com* :: *Lists hosted by > gradwell.com* > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > > -- > These lists are syncronised with the CFDeveloper forum at > http://forum.cfdeveloper.co.uk/ > Archive: > http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > CFDeveloper Sponsors and contributors:- > *Hosting and support provided by CFMXhosting.co.uk* :: > *ActivePDF provided by activepdf.com* > *Forums provided by fusetalk.com* :: *ProWorkFlow > provided by proworkflow.com* > *Tutorials provided by helmguru.com* :: *Lists > hosted by gradwell.com* > > To unsubscribe, e-mail: [EMAIL PROTECTED] > -- These lists are syncronised with the CFDeveloper forum at http://forum.cfdeveloper.co.uk/ Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ CFDeveloper Sponsors and contributors:- *Hosting and support provided by CFMXhosting.co.uk* :: *ActivePDF provided by activepdf.com* *Forums provided by fusetalk.com* :: *ProWorkFlow provided by proworkflow.com* *Tutorials provided by helmguru.com* :: *Lists hosted by gradwell.com* To unsubscribe, e-mail: [EMAIL PROTECTED]
