Blog

Brad Wood

September 19, 2012

Spread the word


Share your thoughts

 

In ColdBox, controllers or event handlers as we call them are defined as CFCs.  Part of the power of this is that you can share and extend code in your applications by simply extending one handler with another.  
 
Imagine a reporting framework where a number of reports will all have a criteria page, validation, execution, and export data action with most of the logic, views, layouts, and models the same between every report while still allowing for customizations on a per-report basis.
 
You could set up a base report handler that contained shared stuff like so:
 
component name="BaseReport" extends="coldbox.system.eventhandler" output="false"
{
  property name="ReportService" inject;
  
  public function init(Controller){
    super.init(arguments.controller);
    return this;
  }
  
  function criteria(Event, rc, prc){
    // Common Code
  }
  
  function execute(Event, rc, prc){
    // Common Code
  }
  
  function showResults(Event, rc, prc){
    // Common Code
  }
  
}
 
And then extend it per report with concrete handlers that add their own customizations:
 
 

component name="MyReport" extends="BaseReport" output="false"

{

  property name="myReportDAO" inject;

 

  function criteria(Event, rc, prc){

    super.criteria(Event, rc, prc);

    // Add in custom goodness for this report.

  }

}

 
More info on how amazing handlers are here: http://wiki.coldbox.org/wiki/EventHandlers.cfm
 
P.S. Remember, since ColdBox is chock full of choices, your event handlers don't have to eventually extend coldbox.system.eventhandler.  We could leave off the extends and the super.init() call on our BaseReport and WireBox will use virtual inheritance to ensure the handler has everything it needs.
 

 

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