Hello and welcome to ColdBox.
If all your events are part of the same HTTP request, you should simply be able to use the request collection or private request collection (passed into each action as rc and prc). Those structs are part of the request context which lives in the request scope and is available to all events, views, and layouts in that request.
Alternatively, if you need access to these values in your model (which mostly lives outside the framework), then you can persist a bean in the request scope via Wirebox. Or, if you really want to, just stick the data directly in the request scope. (There’s no request storage plugin, but you could create one too if you wanted)
The flash scope in ColdBox is used to persist values between multiple HTTP requests. It is stored in session by default.
So, lots of options. Feel free to ask more questions if you need more direction.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Thanks Brad. I was under the impression that I had to (1) declare which variables I wanted to persist between events (due to the existence of the ‘persist’ arg in setNextEvent() and that (2) these could only be simple datatypes. I’m not having luck with rc, but need to do more tinkering (and reading!) on my end. Thanks again.
A quick definition;
-
runEvent(“event.name”) executes a ColdBox event right there in the request just like you would make a function call (All part of the same HTTP request)
-
setNextEvent(“event.name”) This ends the current request and redirects the users browser (via cflocation 302 redirect) to a new event (in a new HTTP request)
So, you can call runEvent() multiple times from wihtin a handler or view on the same page request and the rc (request collection) will be the same struct available to all those events.
However, every time you call setNextEvent the next event to run will have a new rc since it is a different HTTP request from the browser. That’s why the setNextEvent has the persist attribute. Persist uses flash RAM automatically to make the keys you specify available on the next event.
Does that help?
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Thanks Brad that does help.
The ‘flash scope’ is similar to what I’ve used in Grails in the past. Is there a generally accepted preference in the Coldbox community between (1) passing the variables that you want from one setNextEvent() call to the next and (2) using the flash scope directly. I set up the Flash scope on the (existing) system that I’m working on to use the session scope and to clear out at the end of a request (via Main.onRequestEnd()). That way I can set a variable once using flash.put() and not have to worry about persisting it, declaring/re-declaring it, etc.
Thanks again for your help and for your feedback on my hopefully not hack-y way of using the flash scope 
If you’re using setNextEvent(), I wouldn’t bother manually fiddling with the flash scope since you can simply say what keys you want to be persisted and they will just magically be there after the redirect. There’s nothing wrong with using the flash scope manually either, but my favorite method is just to pass whatever I want in the query string. That way the user can refresh the page as many times as they want or bookmark it and I don’t have to worry about errors because the flash scope has been “used”. If I need to persist complex objects, I usually just session scope the CFCs or persist them manually with the sessionStorage plugin.
This is just my personal preference though. You won’t find a ColdBox “best practice” on this kind of thing since we’re typically a rather un-opinionated framework. Unlike a platform such as Rails that would give you one way to do something, we give you 3 ways and let you choose. Try several ways and do what works best for your needs. At this point, I don’t hear you saying anything crazy, so you can’t be too far off in the weeds
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com