Provide a way for a parent app (or a parent module) to override a module's settings that it is dependent on. If we start thinking of modules as stand-alone libraries that can be uninstalled or reinstalled at any time we don't want to have to modify the core code of someone elses module after we install it to change the settings I want.
I'm thinking something similar to jQuery where a library will usually have a DEFAULTS object you can override, but you're never expected to install a jQuery plugin and then modify the core code to add your settings.
Give apps and parent modules a "modules" struct in their settings like how it's stored now, but you could actually declare it in the config. The actual modules settings will be appended to this existing struct.
/config/ColdBox.cfc or /modules/parentModule/ModuleConfig.cfc
Any thoughts on this? I'd really like to see this as more and more modules out there that we've written all have custom solutions for putting settings in the ColdBox config which aren't consistent. Having a single convention for overriding a module's settings would be very nice. For instance, looking at the storages module right now and in my opinion we shouldn't be creating custom structs in the config but just using a standard convention for settings.
I actually disagree on this. I like where you do not need to touch the module for configuration but rely on the parent application to configure the modules. Having a way that the module reads the parent settings for more customized structs is clean and efficient.
Unless I am misunderstanding your ticket.
I think you are misunderstanding the ticket. What I want is exactly what you said-- the ability to drop a third-party module into my app that has configurable settings, and simply putting those settings in the parent app in such a way that the module "picks them up" and uses them to override its defaults. I think we're on the same page there.
This ticket is to create a convention for that to happen automatically via convention without the module authors to write special code to do so like is what happens now. Defining a standard way to override module settings will make them more intuitive and easy to use because everyone will follow the same pattern and not need to write boilerplate code. it will just work.
Look at lines 36-41 in this file:
This is what I DON'T want to have to do as a module author. ColdBox should be doing this for me in a predictable manner.
Ahh ok, now I get it. Ok, that sounds good. Will have to defer this to our first patch release though.