ColdBox, the previous lesson, comes with routing, dependency injection, caching, and logging all built in. FW/1 (Framework One) was created in 2009 as a deliberate reaction against that kind of complexity, a single file focused on getting out of the way, though it still ships with its own dependency injection and aspect-oriented programming tools.
Learning Objectives
After completing this lesson, you'll be able to:
- Explain FW/1's convention-over-configuration approach to mapping URLs to controllers.
- Recognize FW/1's folder structure and naming conventions.
- Compare FW/1's minimal footprint against ColdBox's fuller feature set.
How a Request Flows Through FW/1
URL Arrives
e.g. index.cfm?action=users.list
Single Front Controller
Application.cfc dispatches by convention
Controller CFC Runs
a function matching the action name
Matching View Renders
found by folder/file naming convention
Convention Over Configuration
FW/1 maps a URL straight to a controller and view by folder and file naming, with minimal setup required to wire that up, which is its main selling point against a fuller framework.
| Folder | Holds |
|---|---|
| controllers/ | Controller CFCs, one function per action |
| views/ | .cfm templates, matched to a controller/action by naming convention |
| model/ (with services/ and beans/ subfolders) | The application's data and business logic layer |
| layouts/ | Shared page wrapper templates applied around a view's output |
A view at views/users/list.cfm is reached through ?action=users.list, the same folder-path-to-action-name convention runs throughout FW/1.
FW/1's Companion Tools: DI/1 and AOP/1
FW/1 isn't purely a router. It ships alongside two companion tools: DI/1 for dependency injection (declare a property on a controller and FW/1 and DI/1 work together to inject the right instance automatically) and AOP/1 for aspect-oriented programming. The framework stays a single file, but dependency injection specifically isn't something you have to add separately.
A Real Detail: Controllers Are Cached by Default
FW/1 caches controller instances by default, which is fine in production but means a code change during development won't show up on a normal page refresh. Appending ?reload=true to the URL forces FW/1 to pick up the change.
FW/1 vs ColdBox
| FW/1 | ColdBox | |
|---|---|---|
| Setup | Minimal, a single Application.cfc | More structure out of the box |
| Dependency injection | DI/1, included as a companion tool | WireBox, included |
| Aspect-oriented programming | AOP/1, included as a companion tool | Built into WireBox |
| Caching (framework-level objects) | Not a separate built-in pillar | CacheBox, included |
| Logging | Not a separate built-in pillar | LogBox, included |
| Best fit | Smaller apps, or teams that want a minimal single-file footprint | Larger apps that benefit from a fuller built-in toolset |
The real difference isn't "FW/1 has no DI", both frameworks give you dependency injection. It's that ColdBox bundles caching and logging as additional built-in pillars alongside DI, where FW/1 stays focused on routing plus DI/AOP and leaves caching/logging to whatever else the application needs.
Common Beginner Mistakes
Assuming FW/1 has no dependency injection since it's the minimal framework
It does, through its companion tool DI/1. What FW/1 doesn't bundle as a separate built-in pillar is caching and logging the way ColdBox's CacheBox and LogBox do.
Assuming FW/1 and ColdBox share identical naming conventions
They're both convention-based, but the specific folder names and terminology (Controller vs. Handler, for instance) differ between the two frameworks.
Best Practices
- Choose FW/1 when a project's size and team genuinely don't need a fuller framework's built-in DI/caching/logging, not by default.
- Keep the same Model/View/Controller discipline from the Introduction to MVC lesson regardless of which framework enforces (or doesn't enforce) it.
Interview Questions
What's the core trade-off between FW/1 and ColdBox?
Both give you dependency injection, FW/1 through its companion tool DI/1, ColdBox through WireBox. The real difference is that ColdBox also bundles caching (CacheBox) and logging (LogBox) as additional built-in pillars, where FW/1 stays focused on routing plus DI/AOP and leaves caching and logging to whatever else the application needs. FW/1 trades that broader built-in toolset for a smaller, single-file footprint.
What does 'convention over configuration' mean in the context of FW/1?
A controller's action and its matching view are connected automatically based on folder/file naming, rather than registering each route explicitly in configuration.
Summary
In this lesson, you saw how FW/1 maps a request to a Controller and View through naming convention alone, its folder structure, and how its minimal footprint compares to ColdBox's fuller built-in toolset.
What's Next?
The next lesson covers CommandBox, the command-line tool used to run and manage both ColdBox and FW/1 applications (and plain CFML ones) locally.