ColdBox 7 brings us many great new features, but let’s not overlook a simple one that improves the organization of our ColdBox application's moduleSettings
.
It Grew and Grew and Grew
It all began with a simple ColdBox application. The app was born with the CommandBox command coldbox create app
. This scaffolded the skeleton of the app. By default the directory structure includes the config
folder, which contains a Coldbox.cfc
configuration file.
The moduleSettings
directive, in the Coldbox.cfc, is used to set the configuration of individual modules that are installed in the application. Initially, no modules are necessary; therefore, the moduleSettings
object can remain empty.
/**
* --------------------------------------------------------------------------
* Module Settings
* --------------------------------------------------------------------------
* Each module has it's own configuration structures, so make sure you follow
* the module's instructions on settings.
*
* Each key is the name of the module:
*
* myModule = {}
*/
moduleSettings = {};
The scalability of a ColdBox application is exceptional. This is due to its modularity. Modules can be easily aggregated, as they are needed to add functionality to the application. To install the module CBSecurity, for example, run the following command ( leveraging CommandBox of course ):
#Latest version
install cbsecurity
After the installation is complete, you configure the module by creating a cbsecurity
key in the moduleSettings
. Check out the CBSecurity documentation to learn how to configure this module. The cbsecurity settings alone can consume quite a bit of lines of the configuration file, especially if you leave comments.
![Astro reviewing the Coldbox.cfc](webp/astro-coldbox-cfc.webp)
![Astro reviewing a growing Coldbox.cfc](webp/astro-coldbox-cfc-02.webp)
![Astro looking for code in a very long Coldbox.cfc](webp/astro-coldbox-cfc-03.webp)
CBsecurity, StacheBox, cbAuth, and cbSwagger are just a few of the many modules that became part of the now-not-so-simple app. Each of those modules has its own set of settings inside the moduleSettings
object. In addition, settings can also differ between the development and the production environments. With all these additions, the Coldbox.cfc can grow very very very long!
ColdBox 7 to the Rescue
![Astro Ninja chopping the Coldbox.cfc file](webp/ninja-sword-cuts.webp)
ColdBox 7 now allows module override configurations outside the ColdBox.cfc. Each module can have its own configuration file, placed inside the config
directory. The structure takes the following form:
|--config
|--modules
|--cbsecurity.cfc
|--stachebox.cfc
|--cbauth.cfc
|--cbswagger.cfc
|--mymodule.cfc
Like the Coldbox.cfc, each of the module configuration files has its own configure()
method, which returns a settings struct.
component{
function configure(){
return {
key : value
};
}
}
What do you do when you must set a setting with a value in the development
environment and a different value in the production
environment? You can create new development
or production
methods in the same configuration file, and when run on the correct environment, these methods will be executed and will override the original module settings.
component{
function configure(){
return {
key : value
};
}
/**
* Executed whenever the development environment is detected
*/
function development( settings ){
// overides to the original settings struct
settings.key = value;
}
}
Summary
Thanks to ColdBox 7 and its new config object override convention, the configure()
function inside the Coldbox.cfc can be much smaller. It is also faster to locate and edit the configuration settings from a particular module because they are all isolated in one single file.
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
Clean Code: A Handbook of Agile Software Craftsmanship
Add Your Comment