Settingslogic is a simple configuration / settings solution that uses an ERB enabled YAML file. It has been great for our apps, maybe you will enjoy it too. Settingslogic works with Rails, Sinatra, or any Ruby project.
So here is my question to you.….is Settingslogic a great settings solution or the greatest?
* Documentation: rdoc.info/projects/binarylogic/settingslogic * Repository: github.com/binarylogic/settingslogic/tree/master
Install from rubyforge/gemcutter:
sudo gem install siliconsalad-settingslogic
Or as a Rails plugin:
script/plugin install git://github.com/binarylogic/settingslogic.git
Settingslogic does not have any dependencies on Rails. Installing as a gem is recommended.
Instead of defining a Settings constant for you, that task is left to you. Simply create a class in your application that looks like:
class Settings < Settingslogic source "#{Rails.root}/config/application.yml" namespace Rails.env end
Name it Settings, name it Config, name it whatever you want. Add as many or as few as you like. A good place to put this file in a rails app is app/models/settings.rb
I felt adding a settings file in your app was more straightforward, less tricky, and more flexible.
If multiple files are passed on the source line, comma-separated, they will be loaded in order, with settings in later files overriding any existing keys. This allows you to, for instance, maintain a global settings file in source control, while allowing each developer to override individual settings as needed. Files that are specified but which do not exist will simply be ignored. Thus you can safely do the following without requiring the presence of application_local.yml:
class Settings < Settingslogic source "#{Rails.root}/config/application.yml", "#{Rails.root}/config/application_local.yml" namespace Rails.env end
Notice above we specified an absolute path to our settings file called “application.yml”. This is just a typical YAML file. Also notice above that we specified a namespace for our environment. A namespace is just an optional string that corresponds to a key in the YAML file.
Using a namespace allows us to change our configuration depending on our environment:
# config/application.yml
defaults: &defaults
cool:
saweet: nested settings
neat_setting: 24
awesome_setting: <%= "Did you know 5 + 5 = #{5 + 5}?" %>
development:
<<: *defaults
neat_setting: 800
test:
<<: *defaults
production:
<<: *defaults
Note: Certain Ruby/Bundler versions include a version of the Psych YAML parser which incorrectly handles merges (the ‘<<` in the example above.) If your default settings seem to be overwriting your environment-specific settings, including the following lines in your config/boot.rb file may solve the problem:
require 'yaml' YAML::ENGINE.yamler= 'syck'
>> Rails.env => "development" >> Settings.cool => "#<Settingslogic::Settings ... >" >> Settings.cool.saweet => "nested settings" >> Settings.neat_setting => 800 >> Settings.awesome_setting => "Did you know 5 + 5 = 10?"
You can use these settings anywhere, for example in a model:
class Post < ActiveRecord::Base self.per_page = Settings.pagination.posts_per_page end
Often, you will want to handle defaults in your application logic itself, to reduce the number of settings you need to put in your YAML file. You can access an optional setting by using Hash notation:
>> Settings.messaging.queue_name => Exception: Missing setting 'queue_name' in 'message' section in 'application.yml' >> Settings.messaging['queue_name'] => nil >> Settings.messaging['queue_name'] ||= 'user_mail' => "user_mail" >> Settings.messaging.queue_name => "user_mail"
Modifying our model example:
class Post < ActiveRecord::Base self.per_page = Settings.posts['per_page'] || Settings.pagination.per_page end
This would allow you to specify a custom value for per_page just for posts, or to fall back to your default value if not specified.
Raising exceptions for missing settings helps highlight configuration problems. However, in a Rails app it may make sense to suppress this in production and return nil for missing settings. While it’s useful to stop and highlight an error in development or test environments, this is often not the right answer for production.
class Settings < Settingslogic
source "#{Rails.root}/config/application.yml"
namespace Rails.env
suppress_errors Rails.env.production?
end
>> Settings.non_existent_key
=> nil
Each of these frameworks uses a set convention for settings, which actually defines methods in the global Object namespace:
set :application, "myapp" # does "def application" globally
This can cause collisions with Settingslogic, since those methods are global. Luckily, the solution is to just add a call to load! in your class:
class Settings < Settingslogic source "#{Rails.root}/config/application.yml" namespace Rails.env load! end
It’s probably always safest to add load! to your class, since this guarantees settings will be loaded at that time, rather than lazily later via method_missing.
Finally, you can reload all your settings later as well:
Settings.reload!
This is useful if you want to support changing your settings YAML without restarting your app.
This change allows you to set multiple source files. The main purpose behind adding it was to avoid the huge size of application.yml. Now you can simply have ‘defaults.yml’, ‘production.yml’, ‘development.yml’ and so on. In your class you can have something like:
class Settings < Settingslogic source ["#{Rails.root}/config/settings/defaults.yml", "#{Rails.root}/config/settings/#{Rails.env}.yml"] end
Sources are merged in the same order as they are positioned in the array; later settings overwrite earlier ones. Deep merge is used, so settings will be merged on all levels.
It is possible to add additional settings (hash, path_to_file or array_of_paths) by using Settings.load_source(hash_or_file_or_array, section, options). This can be useful for example in case of a lib that needs settings. Lib can be loaded with its own settings which can be later extended by part of application ones. It is possible to pass additional options:
-
{:replace => true} to replace existing settings with the new ones
-
{:deep_delete_nil => true} to deeply delete nil settings, ex. {:a=>{:b=>nil}}.deep_delete_nil => {}
Copyright © 2008-2010 Ben Johnson of Binary Logic, released under the MIT license. Support for optional settings and reloading by Nate Wiger.