setting page variables in onRequestStart

hi is it possible to set page variables in the onRequestStart method of the application.cfc? if i enter the following code in the application.cfc: <cfset variables.myVariable = "myVariable"> and the following code in my page: <cfoutput>#myVariable#</cfoutput> i get an error message when running a page saying myVariable is not defined

Right, you can't do that. The variables scope in App.cfc isn't copied to the template. Unless you use onRequest. But that has some drawbacks as well. Why not simply simply use the Request scope? On Thu, May 22, 2008 at 3:10 PM, Richard White <richard@j7is.co.uk> wrote: ----- Excess quoted text cut - see Original Post for more -----

thanks Raymond i haven't yet looked into the request scope but will do now! thanks again ----- Excess quoted text cut - see Original Post for more -----

> Why not simply simply use the Request scope? Verbosity. The idea he is working on is doing something similar to the way MG3 creates the 'helper scope' for udfs. I think helpers.myUdf() is preferable to request.helpers.myUdf() though its all good. Clearly with MG, the helper/event/viewstate variables are setup outside of any cfcs and I hadn't figured that in the sample code I came up with (I still use application.cfm). Dominic -- Blog it up: http://fusion.dominicwatson.co.uk

I'd argue that variables he is setting on - every- page request should be segregated for normal page variables. If I see request.siteURL for example, it flags it as a variable that is always available, as opposed to just 'X' for example. On Thu, May 22, 2008 at 5:15 PM, Dominic Watson <watson.dominic@googlemail.com> wrote: ----- Excess quoted text cut - see Original Post for more ----- -- =========================================================================== Raymond Camden, VP of Software Dev, Broadchoice Email : ray@camdenfamily.com Blog : www.coldfusionjedi.com AOL IM : cfjedimaster Keep up to date with the community: http://www.coldfusionbloggers.org

> I'd argue that variables he is setting on - every- page request should > be segregated for normal page variables. If I see request.siteURL for > example, it flags it as a variable that is always available, as > opposed to just 'X' for example. Sure, I'd be with you usually; but this is an entire 'pseudo scope'. Would you argue for MG to use request.viewstate over just viewstate? That wouldn't be so bad actually thinking about it; always bugged me a little referencing viewstate without a scope lol Dominic -- Blog it up: http://fusion.dominicwatson.co.uk

variables.viewState? On Thu, May 22, 2008 at 9:21 PM, Dominic Watson < watson.dominic@googlemail.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

> variables.viewState? Ok Mr Pedant, pick up on the useless bit of the post damn you :p -- Blog it up: http://fusion.dominicwatson.co.uk

Err, how is it a 'pseudo-scope"? The request scope is a real scope (don't give it any confidence issues!) just as much as Variables. And I'll repeat my earlier assertion - that maybe seeing Request.Foo will help it stand out compared to Variables.goo. On Thu, May 22, 2008 at 8:21 PM, Dominic Watson <watson.dominic@googlemail.com> wrote: ----- Excess quoted text cut - see Original Post for more ----- -- =========================================================================== Raymond Camden, VP of Software Dev, Broadchoice Email : ray@camdenfamily.com Blog : www.coldfusionjedi.com AOL IM : cfjedimaster Keep up to date with the community: http://www.coldfusionbloggers.org

During our site rewrite, we opted to use the request scope over the variables scope for all "view" (CFM) pages. We use onRequestStart() to make sure certain global site variables are available in the request scope. After reading this article: http://www.schierberl.com/cfblog/index.cfm/2006/10/16/memoryLeak_variablesScope it turns out using the request scope everywhere was a great boon to the project. One of our legacy applications uses Application.cfm, relies on the variables scope and has major memory issues. If you look down in his Summary, #4 says "Calling structClear(variables) in onRequestEnd.cfm will destroy unwanted references tied to variables scope". We added this code to one server in the middle of the day and watched the memory on that server drop like a rock as soon as it deployed. We promoted it to the rest of the servers and they've all been behaving much better ever since. -- Adrian ----- Excess quoted text cut - see Original Post for more -----

Just so I'm clear on this... You are using the request scope for EVERY variable you set or ONLY the global variables? In other words, do you use the variables scope at all on the "view" pages? Would you have used: <cfquery name="request.myQuery" ...> ? m!ke During our site rewrite, we opted to use the request scope over the variables scope for all "view" (CFM) pages. We use onRequestStart() to make sure certain global site variables are available in the request scope.

My only problem with Request scope is that its available _everywhere_. I understand you can be a good developer and not use it in your model or elsewhere but I still dislike the request scope for that reason. Being a person that is constantly working on framework and components to be used in my company I cherish encapsulation and request scope spits in the face of that. Sure Application and Session do too but they server a good purpose for carrying state so I like them :)  I do like your point about global variables for the life of the request and being easy to differentiate between those and page variables. I am with Dave though maybe Application or Session would be a better place for that info? Just my 2 cents. Also check out what Sean did with Application.cfc in fusebox very clever to get around most of the limitations/issues with onRequest. Adam Haskell On Thu, May 22, 2008 at 4:17 PM, Raymond Camden <rcamden@gmail.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

> Err, how is it a 'pseudo-scope"? The request scope is a real scope > (don't give it any confidence issues!) just as much as Variables. And > I'll repeat my earlier assertion - that maybe seeing Request.Foo will > help it stand out compared to Variables.goo. ;) You mis-read me (and I express badly). For example, MG3 has introduced the 'helpers' 'pseudo-scope'. With this, you put all your UDFs in a folder called helpers and the app automagically places them all in a variable called helpers. So then, in your cfms, or even your cfcs (yuck), you could do: <cfset result = helpers.stringUdfs.myStringFunction('foo')> So here, 'helpers' is sort of a 'pseudo-scope'. Sure, it's just a structure in the variables scope that has collections of udfs as its keys, but I think the 'pseudo-scope' is a good term for it. This is what I was trying to recreate for Richard - but I failed to calculate the inability to set anything in the variables scope in application.cfc (the 'global' variables scope outside of the cfc that is). The request scope is absolutely fine. However, in this case, we were putting the collection of udfs in the application scope and then wanting to create a 'pseudo-scope' for them to avoid verbosity. If that isn't possible, then the best place for them is just to stay in the application scope (logically where they belong): <cfset result = application.helpers.myStringFunction('foo')> But yeh, I completely agree that variables should sit in the scopes where they belong - but I also like the idea of creating 'pseudo-scopes' if it readable to do so ;) Dominic -- Blog it up: http://fusion.dominicwatson.co.uk

----- Excess quoted text cut - see Original Post for more ----- I agree with you for most app building. However, I was recently tasked with building a pretty much flat site but where ColdFusion templating would be really useful. For this simple app, I just setup onRequestEnd.cfm to be the HTML template that outputted #request.header# for various page specific header tags (javascript, etc) and #request.body# for the main content.  Each individual page would then just savecontent to request.body and possibly request.header to be outputted later in onRequestEnd.cfm. The request scope was the logical place for these variables. (I'm sure that onRequestEnd tactic must have been / is a common tactic - not claiming originality!) Dominic -- Blog it up: http://fusion.dominicwatson.co.uk

> In other words, do you use the variables scope at all on the "view" > pages? > > Would you have used: > > <cfquery name="request.myQuery" ...> ? If it's really a view page, in an MVC pattern, you wouldn't have any CFQUERY tags in it. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Training: Adobe/Google/Paperthin Certified Partners http://training.figleaf.com/ WebManiacs 2008: the ultimate conference for CF/Flex/AIR developers! http://www.webmaniacsconference.com/

Of course, but that was just an example. m!ke > In other words, do you use the variables scope at all on the "view" > pages? > > Would you have used: > > <cfquery name="request.myQuery" ...> ? If it's really a view page, in an MVC pattern, you wouldn't have any CFQUERY tags in it. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/

----- Excess quoted text cut - see Original Post for more ----- Yeah, that was really for the benefit of others, not for you personally. That said, I've seen a lot of people use only Request variables in their pages for this sort of thing. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

----- Excess quoted text cut - see Original Post for more ----- I read that article, and while I'm glad this turned out well for you, there seems to be a serious misunderstanding in the article about how Java garbage collection works in CF. The garbage collection doesn't run after every request, by default - and you wouldn't want it to, either. Garbage collection is an expensive operation. And just destroying the unwanted references in onRequestEnd.cfm or the onRequestEnd method in Application.cfc isn't going to change that - it just means that those variables will be immediately eligible for garbage collection whenever it runs, as long as those variables have no other references in the stack. This isn't a memory leak. Java will eventually reclaim and reallocate that memory. That said, I'm not sure what's different about using Request variables in this way, since they're just references like any other reference, and the values stored in the heap should be destroyed by the garbage collector the same way. Finally, if you're creating truly global site variables, why not just use the Application scope? That's what it's for, after all. You don't have to worry about the silly locking issues like you did with CF 5 and earlier. Of course, if things are working as they are, it's probably not worth changing now. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!