Blog

Tip of the Week: Implicit View Dispatch

Brad Wood December 05, 2012

Spread the word

Brad Wood

December 05, 2012

Spread the word


Share your thoughts

 

In the past we've talked about implicit views in ColdBox which mean that if the action in your event handler doesn't call setView() explicitly, ColdBox will use conventions to try and find the view to render.  Well, ColdBox also supports something called Implicit View Dispatch which goes one step further and allows you to dispatch a view to the user without running any event at all.
 
What are the use cases?  Well, perhaps you have a completely static view like a contact us page and creating a method in a handler somewhere would just be pure boilerplate.  We can tell ColdBox to just send the view directly back to the user (using the default layout). 
 
Or perhaps you're slowly integrating ColdBox into a legacy app and you want to still serve up a legacy CFM page while using ColdBox's routing mechanisms.  Again, we can ease into ColdBox without creating handlers for all those legacy pages yet.
 
So, how does it work?  Very simply, and unsurprisingly similar to how implicit views work.  If ColdBox can't located the package/handler or the action specified by your event, it uses a /views/[package/]handler/action.cfm convention to try and locate a view to return.
 
Consider a URL that looks like this:
 
mySite.com/index.cfm?event=contact.about
 
(Or the following equivalent for you people using the SES Interceptor and rewrites)
 
mySite.com/contact/about
 
If the "contact" handler doesn't exist, or does exist but doesn't have an "about" action, then ColdBox will look for the following view to dispatch directly:
 
/views/contact/about.cfm
 
If you have external view locations defined, ColdBox will check them as well before finally giving up and throwing an error.
 
 
P.S. It is also possible to add SES routes that directly dispatch a view without running an event like so:
 
addRoute(pattern='/AboutUs',view='contact/about');
 
That would make the following URL dispatch the same view as above, but with an even prettier URL:
 
mySite.com/AboutUs
 

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