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 heart of a ColdBox application is the configuration CFC. That is where you set initialization variables of your app and other third-party modules.

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.

---

---

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

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.

― Robert C. Martin,
Clean Code: A Handbook of Agile Software Craftsmanship