Blog

Brad Wood

November 14, 2012

Spread the word


Share your thoughts

 

In a ColdBox request, form, URL, and remote (proxy request) variables are merged together into the request collection which is accessible via event.getCollection() or as the "rc" struct passed into every action in your handlers.  Data needed to process that request can be added and retrieved from this collection at any time during the request as it is available to any layouts and views as well.  
 
What you may not now however, is there is also a private request collection.  This one also lives in the event object and can be accessed via event.getCollection(private=true) or as the "prc" struct that is also passed into each action.  
 
So, what's the difference between the regular request collection and the private request collection?  Not much in the way of implementation.  It's all in how you use them to help organize your code.  ColdBox best practices are to reserve the regular request collection for only form, URL, and remote variables as they were received from the client.  More importantly, these are the incoming variables from your user that control how the request will process.  A good example would be the productID variable coming into a product detail page.  
 
The private collection is best used by everything else, especially if it has no direct bearing on how the page is processed.  An example could be a service that the handler wants to pass along to the view, or a result set of data that will be used in outputting the view.
 
 
P.S. One of the reasons it's ideal to only store items in the rc that control what displayed on the page is because ColdBox creates a hash of the rc at the beginning of your request which is used for event caching to ensure a different version of the event's output is cached for each combination of incoming criteria.
 

Add Your Comment

Recent Entries

TestBox 7 : Real-Time Streaming, a Browser IDE, and a Major Leap for BoxLang

TestBox 7 : Real-Time Streaming, a Browser IDE, and a Major Leap for BoxLang

TestBox 7.x series continues our mission to be the best testing framework for BoxLang and CFML. This release is focused heavily on BoxLang CLI runner enhancements, real-time streaming test execution via SSE, a powerful dry run capability, the brand-new TestBox RUN web IDE, and significant quality-of-life improvements for developers working in both BoxLang and CFML environments.

Luis Majano
Luis Majano
March 17, 2026
From Legacy Risk to Modern Agility: A Phased Modernization Roadmap for CFML Teams

From Legacy Risk to Modern Agility: A Phased Modernization Roadmap for CFML Teams

Many organizations running CFML applications today face the same challenge.

Their systems still work.

They support core business processes.

They generate revenue.

But at the same time, those platforms are increasingly exposed to risk.

Unsupported runtimes, operational fragility, security exposure, and difficulty integrating with modern systems are becoming more common in environments still running older versions of Adobe ColdFusion or Lucee.

The quest...

Cristobal Escobar
Cristobal Escobar
March 16, 2026
Introducing the BoxLang Spring Boot Starter: Dynamic JVM Templating for Spring

Introducing the BoxLang Spring Boot Starter: Dynamic JVM Templating for Spring

Spring Boot developers know the pain of evaluating view technologies. Thymeleaf is great — until you need more expressiveness. FreeMarker is powerful — until the syntax fights you. What if you could write templates in a dynamic JVM language that gives you the full power of the platform, feels natural, and requires zero setup to integrate?

Meet the BoxLang Spring Boot Starter.

Luis Majano
Luis Majano
March 13, 2026