Cool. Would you like for me to break it out of cfscript and into actual cffunction tags? Also, I can change “local” to “private” if you wish.
Just let me know and I’ll tidy it up.
-Dutch
Yea, I am debated about it. I can definitely see a benefit of having a private context withing the normal public event context. I am just trying to debate if it is worth the extra code in it.
Let's put it on Trac and we'll see if we implement this in the future..
Some things just need time to see if it's worth the coding...
I would like to see it in the core, for use with viewlets if nothing else.
I think what’s confusing here is how the thread started.
Dutch’s decorator would be the ideal approach, since there was no alternative.
I think extending the core to allow for private context would be used more frequently then you think once people are aware of the option.
Although, it is worth looking at performance pros and cons - however, if its just extra code, I can’t seeing it being enough to weigh the framework down noticably.
Coldbox is not known for being minimal, it’s claim to fame is its overwhelming features and documentation, why stop now 
I would like to see it in the core, for use with viewlets if nothing else.
I think what’s confusing here is how the thread started.
Dutch’s decorator would be the ideal approach, since there was no alternative.
After thinking about it, I’m going to agree with Tom in that a private request collection should be in the core.
Just a little background on why I created the local/private scope decorators. I was writing some integration tests, and I wanted to “param” some variables with default values (mostly booleans), but I didn’t want them to possibly be overwritten by form or url variables. I could then set these variables in my tests to test the flow of my application.
As Tom mentioned, this really won’t produce much overhead and most likely won’t be the straw that broke the camel’s back. I think the biggest advantage of including a private rc in the core is that we would have the advantage of having persistPrivateVariables() available in the controller. The biggest difference from the rc and the private rc is that the private rc will initially be empty and can’t be populated from form and url variables.
-Dutch
Ok I like it.
Now, question here. Should the private collection be its own class available via the framework super type, or be tightly bounded to the event object, so it can exist side by side with the public collection? THis is a huge design, please comment?
Luis
So, I think the current requestContext bean actually does enough already. No sense in adding a bunch of functionality there.
I think it’s worth the effort to create a bean called something like privateRequestContext.
While it won’t be a copy of requestContext, it’ll contain some familiar functions - getValue(), setValue(), getCollection(), setCollection(), clearCollection(), collectionAppend(), valueExists(), paramValue(), etc.
A single function will be added to requestContext called getPrivateContext().
In the controller, we could then interface with it like this:
prc = event.getPrivateContext().getCollection();
-Dutch
I am liking this idea, anybody else ideas, comments thoughts??
yip, I like it....
One addon: facade (prc) in view for event.getPrivateContext().getCollection()
just don’t forget to add persistPrivateVariables() in coldbox.system.controller
Along the lines of what Tom said, it’s really interesting how we spec’d out new, potential functionality, especially when you consider the origins of this thread.
-Dutch
what about a new flash ram object?
I'm coming in late on this discussion. Maybe I'm missing something,
but I honestly think that adding a core private scope within the rc
scope just for exit handlers is overkill. What benefits would this
bring over just putting things in the request collection? If someone
has any examples, I'm curious to hear them. If people are concerned
about accidentally overwriting values, I address that by just
following certain variable naming conventions.
Unless someone convinces me otherwise, I'd be in favor of implementing
it the way Dutch has already -- via a decorator. I'm always in favor
of adding useful features to the core, but we should also be wary of
bloat. Just my 2c.
-Tony
+1
The debate continues…
Ok guys, more feedback on this?
How about some official decorators that ship with ColdBox? or should this be in the Code Depot?
Comments, Suggestions, Etc.
Another feature I am contemplating at the moment is a better API for the Flash Ram object. What are your ideas in this area?
Luis
Luis,
Any interest in creating a decorators/plugins manager aspect of the dashboard to install/uninstall plugins? This does not sound easy but it would enhance the usability of Coldbox. I'd be interested in discussing it with you farther if you are interested in this as a possibility.
Tom