Wheels

Cleaner Configuration in Wheels 3.0: Less Magic, More Clarity

Configuration is one of the first things developers interact with in any framework. In Wheels 2.5, configuration worked — but over time it became harder to reason about where values came from, when they were loaded, and which ones were safe to override.

Wheels 3.0 introduces a cleaner, more predictable configuration system that favors explicit behavior over hidden defaults. In this article, we’ll cover: * How configuration worked in Wheels 2.5 * What changed in Wheels 3.0 * Why reducing “magic” matters * How this improves day-to-day development

# **Configuration in Wheels 2.5** In Wheels 2.5, configuration values could come from multiple places: * Framework defaults * Application configuration files * Environment-specific overrides * Implicit assumptions inside the framework While powerful, this approach had drawbacks: * It wasn’t always clear which value won * Some defaults were silently applied * Debugging config-related issues required deep framework knowledge * Behavior could vary between engines and environments In many cases, developers only discovered configuration issues **after something behaved unexpectedly**.

# **What Changed in Wheels 3.0** Wheels 3.0 simplifies and clarifies configuration loading by focusing on **explicit intent**. Key improvements include: * Clearer separation between framework defaults and application settings * More predictable load order * Fewer implicit fallbacks * Removal of legacy configuration paths * Consistent behavior across Adobe ColdFusion, Lucee, and BoxLang The goal is simple: **when you set a configuration value, it should be obvious when and how it’s used**.

# **Less Magic, More Intent** One of the guiding principles of Wheels 3.0 is reducing hidden behavior. In practice, this means: * Fewer “silent defaults” that change behavior behind the scenes * Configuration files that do what they say — and only that * Easier reasoning about application state Developers should not need to read framework source code to understand how configuration affects their app.

# **A More Logical Configuration Layout** In Wheels 3.0, configuration lives where you expect it to:
``` config/ app.cfm environment.cfm routes.cfm settings.cfm ``` Each file has a clear responsibility: * app.cfm — datasource and application-wide variables * environment.cfm — environment-specific overrides * routes.cfm — routing definitions * settings.cfm — application-wide settings This structure encourages separation of concerns and makes it easier to locate and modify behavior.

# **Environment Configuration Without Surprises** Environment handling in Wheels 3.0 is more predictable: * Environments are resolved earlier in the request lifecycle * Overrides happen in a clear, documented order * Defaults are safer for production environments This reduces cases where: * A setting works locally but not in production * An environment variable behaves differently across engines * Configuration values change based on execution timing

# **Why This Matters in Real Applications** Cleaner configuration directly improves: * Debugging time * Onboarding new developers * CI/CD reliability * Cross-engine compatibility When configuration behaves predictably, developers can focus on **business logic**, not framework internals.

# **Migrating from Wheels 2.5** Most applications will require minimal changes, but during migration you should: * Review existing configuration overrides * Remove reliance on undocumented defaults * Verify environment-specific behavior explicitly While this may surface hidden assumptions, the end result is a more stable and understandable application.

# **Summary** Wheels 3.0’s configuration improvements are not flashy — but they are foundational. By reducing hidden behavior and clarifying how configuration is loaded and applied, Wheels 3.0 offers: * More predictable applications * Easier debugging * Safer defaults * Better long-term maintainability This is part of a broader theme in Wheels 3.0: making the framework easier to reason about, one small improvement at a time.

Comments

Newsletter

Release notes and new posts, once a month. No spam.