Blog

Tip of the Week: Using Interceptors

Brad Wood December 20, 2012

Spread the word

Brad Wood

December 20, 2012

Spread the word


Share your thoughts

 

One of the most powerful parts of the ColdBox framework are interceptors.  Interception points are events that happen over the life cycle of your application or a user request which are broadcast by the framework.  Examples would be preProcess (when a request first comes in), onException (when an error happens), or preViewRender (before a view is rendered).  If you any code you want to execute at those points, or if you want to override/modify the default behavior of the framework, you simply need to register an interceptor to listen for that broadcast event.
 
Interceptors, like most everything else in ColdBox, are implemented as simple CFCs which have a configure() method that is called on their creation.  Then you create as many methods as you want named after the interception points you want to respond to.  
 
For Example:
/interceptors/GateKeeper.cfc
component{
    property name="securityService" inject="model";
 
    function configure(){}
 
    function preEvent(event,interceptData){
        if(interceptData.processedEvent == 'secure.page' && !securityService.loggedIn())  {
            setNextEvent("login.page");
        }
    }
}
 
Then, all you have to do is register your interceptor in the config like so:
interceptors = [
    {class="interceptors.GateKeeper", properties={}}
];
 
Now, the code in our preEvent method will get called upon to run before each event in your application.  This keeps cross cutting concerns nicely encapsulated in a way that can easily be turned on and off without actually touching the parts of the app that they are listening to.
 
Check out the full list of interception points here in the docs:  http://wiki.coldbox.org/wiki/Interceptors.cfm
 
P.S. As if all the built-in ColdBox interception points weren't cool enough, you can create your own custom interceptions in your app like orderCreated, userLoggedIn, or accountDeleted and then write interceptors that listen for them and do special logic.
 

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