Hello,
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:
XMLApplicationLoader.ConfigXMLParsingException
There was no 'AppName' setting defined. This is required by the
framework.
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/
EnvironmentControl.cfc):
component [coldbox.system.web.loader.CFCApplicationLoader] has no
function with name [GETJSONUTIL]
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.
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.
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.
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.
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.
