Environment control in Coldbox.cfc

I'm trying to get the new embedded environment control to work using
the Coldbox.cfc config file (in ColdBox 3.0 M4). In my main config, I
defined my development environment urls:

    environments = {
      dev = ".*\.dev$"

I then defined a dev() function to set some settings to override:

  function dev(){
    coldbox = {
    //Development Settings
    debugMode = true,
    debugPassword = "",
    reinitPassword = "",
    handlersIndexAutoReload = true,
    configAutoReload = true,
    handlerCaching = false,
    eventCaching = false,
    enableDumpVar = true

But when I hit the site, I get this error:

There was no 'AppName' setting defined. This is required by the

I do have AppName defined in the main config file. So it seems like
instead of overriding those settings, it's replacing the whole coldbox
structure with the new settings. Naturally, I'd like the settings to
override instead of having to include ALL of the settings all over
again. So should I be naming the settings struct in my dev() method
something else? Or is this behavior expected?

BTW, when I try to use the EnvironmentControl interceptor instead, I
get this error (line 106 in coldbox/system/interceptors/

component [coldbox.system.web.loader.CFCApplicationLoader] has no
function with name [GETJSONUTIL]

  1. I hope it’s expected behavior as it would mean each environment is self contained which I like. But don’t know off hand.

  2. Here’s how I handle it. Since it’s a CFC, I like to encapsulate any “shared” settings in private functions that append to the struct.

a. So for example, if my dev environment has:

// coldbox directives for DEV
coldbox = {
debugMode = true,

b. I immediately follow that with a call to append the shared settings like so

// Append Shared: Coldbox

c. where getSharedSettings_coldbox() is returning a struct with all of the shared settings for ALL environments.

So if the “appName” is something you consider the same across all environments, I’d simply add it in the getSharedSettings_coldbox() struct rather than in any individual environment.

  • Gabriel

That sounds like a good workaround, Dorioo, thanks.
But honestly, I'm hoping there's a built in way to simply override the
settings that I want for different environments the same way it works
for the xml configuration files using the EnvironmentControl
interceptor. That way you can just redefine as many or as little
settings as you want.


I think you need to put all the ‘coldbox’ settings in the dev environment function as your overriding the initial coldbox settings but not setting all of them up.


For me, that’s actually a scary thought. Cause it would mean that if I don’t declare a setting in my environments, it would automatically use the setting from production! I’d rather my environment break than automatically use production settings. Not so important for the “coldbox” settings but very important once you get into “your settings” information.

But, yes, this is how the XML version worked. Although, I’d say it’s taken a step for the better. :slight_smile:

  • Gabriel

I guess that's the way it should work, then, unless Luis or Sana have
something to add.

But I still feel that if it worked the same way the xml version worked
you could have the best of both worlds. Because you could still do the
same thing you have to do now --- copy the whole coldbox struct into
your environment --- and then you wouldn't have to worry about
accidentally not declaring a setting and it defaulting to production
settings. But for those of us who want the override behavior, we could
just declare those settings.

Just playing devil’s advocate as only the author’s know the intention. Although several things are different in 3.0 and this may be one of them:

It depends on whether you consider the XML version “best”. When I think of what’s best, I usually consider it from a perspective of someone completely new to the framework. The XML version has a greater “shoot yourself in the foot” surface area so I consider self contained environments best. This way, new users are less likely to shoot themselves in the foot early on while those with more experience can make it work with relatively simple changes.

In other words, it’s only the best of both world if you already have some experience with the framework. If you’re completely new to the framework, there’s a higher risk of “bye, bye foot” so not best i.m.o.

  • Gabriel

I see where you're coming from, Gabriel. But I guess my philosophy is
different in that I don't believe in always coddling the newbies,
especially in a framework as well-documented as ColdBox. If someone
does something wrong, I say take responsibility for it and RTFM.

Philosophically, what do you say to the old school procedural coder who is looking to move to a framework, has read all the docs, and is still just crawling because of the significant mind shift involved.

CF has not historically used frameworks, OO, orm, etc. So, if all things considered, a change is minor between coddling and not, I side with coddle and hope it helps someone with the transition.

  • Gabriel

You guys have it wrong, If you override the entire structure in the dev() function, then you overrode THE ENTIRE STRUCTURE.

You need to override what you need, just like the xml counterpart. Or if you like, create a struct with implicit notation and then append it to the target structure with an overwrite argument.

function dev(){
test = {
//Development Settings
debugMode = true,
debugPassword = “”,
reinitPassword = “”,
handlersIndexAutoReload = true,
configAutoReload = true,
handlerCaching = false,
eventCaching = false,
enableDumpVar = true


Or just do single stuff:
coldbox.handlerCaching = false;
coldbox.enableDumpVar = true;

Luis F. Majano
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Ah, very cool, Luis. Don't know why I didn't try that earlier. Thanks!