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

12 Days of BoxLang - Day 4: TestBox

12 Days of BoxLang - Day 4: TestBox

Today we’re celebrating one of the most exciting new additions to the BoxLang ecosystem:

the TestBox BoxLang CLI Runner — a fast, native way to run your TestBox tests directly through the BoxLang Runtime. ⚡

No server required. No CommandBox needed. Just pure, ultra-fast BoxLang-powered testing from the command lineon Windows, Mac, and Linux.

If you’re building modern applications with BoxLang — web apps, CLIs, serverless functions, Android apps, or OS-level utilities — this new feature gives you a unified, flexible testing workflow you can run anywhere.

Victor Campos
Victor Campos
December 13, 2025
12 days of BoxLang - Day 3: SocketBox!

12 days of BoxLang - Day 3: SocketBox!

As BoxLang continues evolving into a modern, high-performance, JVM-based runtime, real-time communication becomes essential for the applications we all want to build: dashboards, collaboration tools, notifications, live feeds, multiplayer features, and more.

That’s where SocketBox steps in — the WebSocket upgrade listener built to work seamlessly with CommandBox and the BoxLang MiniServer. ⚡

Today, for Day 3, we’re highlighting how SocketBox supercharges BoxLang development by giving you fast, flexible, and framework-agnostic WebSocket capabilities.

Maria Jose Herrera
Maria Jose Herrera
December 12, 2025
12 Days of BoxLang - Day 2: CommandBox

12 Days of BoxLang - Day 2: CommandBox

BoxLang + CommandBox: The Enterprise Engine Behind Your Deployments

For Day 2 of our 12 Days of Christmas series, we’re diving into one of the most powerful parts of the BoxLang ecosystem: CommandBox the defacto enterprise servlet deployment platform for BoxLang.

If BoxLang is the language powering your applications, CommandBox is the engine room behind it all. ⚙️

Victor Campos
Victor Campos
December 11, 2025