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

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