Right now all config settings are essentially attr_accessors on Middleman::Application, which has too many methods already. This can cause problems when users try to declare their own instance variables or locals (using page or just in helpers/config.rb). For example, just the other day I saw somebody's middleman project break because they set @source from a page block and it overwrote the location of Middleman's source folder causing things to blow up.
It'd be much nicer if configs were stored on a separate object just to keep them contained. We could also do neat things like have a "config view" that shows all the settings you've chosen (and what their defaults are).
Great idea, thankfull we've already got the set abstraction.
Move configuration into a separate object, that can be reused for ext…
…ension configuration and makes settings, their defaults, and descriptions inspectable.
Switch over to new config methods
OK, that was harder than I thought it would be, especially to preserve backwards-compatibility.
Features of the new system:
I'm not 100% sure how I'll poke into extension options for the config meta page, but this gets me a lot of stuff.
Excellent. I've been building #460 in anticipation of this.
That is, the new extension class is instantiated and doesn't use global config.
Move more things over to new configs. Don't let root be configured
Nice! My thought is that the new extension class can use its own private ConfigurationManager instance per extension and expose it through some property so we can walk through all the extensions and show how they're configured (and what settings are available).
The code readability is greatly improved by this.
Here's a question... should we be using IndifferentAccess for this? I hate the level of complexity it adds to basic objects, but I hate answering bug requests where people's code uses config.js_compressor vs config["js_compressor"] vs config[:js_compressor].
Or maybe only enable indifferent access once we get into a plugin, so we keep our code consistent.
Merging this, so I can use it in my Rack stuff without having to worry about a horrible future merge.
Derp, I didn't even dig into the code. You're already handling all the method_missing crap for "indifferent"
I really don't like IndifferentAccess - in this case, you get methods or symbols, and if you put something else in it tells you you're wrong.