dynamic_configuration 0.3.14 → 0.3.15

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 425ae95c29d5bd5d332340549b603a14bc7763bb
-  data.tar.gz: e7238415edef3f48da4bc43137f2e543cee1823c
+  metadata.gz: a193f927145ad061e46c013dbcf8d9f038733764
+  data.tar.gz: d3d1bfd51da8f1755ef4c2b070446ed0f27c2f69
 SHA512:
-  metadata.gz: d9536a059603c8568aff1c5c62ba84b24c7e6480733104e409c605ddd0cf8a2588e6386f147ee6fff0efef0bc738993955d12dad6446d294169dae19fa04ef18
-  data.tar.gz: 59e496dc3da5fab5eee01485e8a24d574b71386c1f2d637ca8c4ac193f92479dc099f5beb73faef68d908ede187adc3c78165506a4dd0bc4a7ddcabf57b44d6c
+  metadata.gz: 914b381b462dce73c78a7e6725d4aed48ffe52ca7b41b08857fce77e189fc85c2d162fc79856a74c745b6bbb8a7f55923e52114170715be13af625a2ceaeef67
+  data.tar.gz: f3bbb87ec54521bb03df00f16589f02fc638f3e020b6efe843de86d9485d290c6038f2395e526c4a6dd404608b4d6a0d57642a49a67b4845658b760265439f17

data/README

@@ -1,25 +1,24 @@
 # dynamic_configuration
 
-Rails made great innovations in almost all areas of web application
-development, yet it surprisingly does not provide any means for
-application configuration, and each of the so far available plugins I
-have seen had some serious disadvantages. Here are the features that
-differentiate dynamic_configuration from other configuration plugins:
+Dynamic_configuration is a library for storing application settings,
+with the following distinguishing characteristics:
 
- * very easy setup with only two lines of code
+ * very easy setup with only one line of code
 
- * configuration files are very clean-looking Ruby files
+ * setting files are neat-looking Ruby files, with all of Ruby
+   available for specifying the setting values
 
- * in Rails development environment, one doesn't have to restart the
-   server to add/remove/modify a setting
+ * settings are divided into groups, each group defined in a separate
+   file, making it easier to remember individual setting names and
+   maintain the whole configuration
 
- * the settings are divided into groups, each group being defined in a
-   separate file, making it easier to remember individual setting
-   names and maintain the whole configuration
+ * settings can be overridden locally for a given installation (useful
+   for customizing webapp configuration per-server, while keeping
+   default developer settings in Git)
 
- * settings can be overridden per-Rails-environment and locally for a
-   given installation (useful for customizing the configuration
-   per-server, while keeping the core settings in Git)
+ * Rails-friendly, for example settings can be overwritten
+   per-Rails-environment, they are also automatically reloaded on
+   every request in Rails development environment
 
  * throughout field- and unit- tested
 
@@ -27,61 +26,42 @@ Developed as part of my work for http://www.tutoria.de/.
 
 ## Setup
 
-### Rails 3 application:
+After adding dynamic_configuration to your Gemfile, or installing and
+requiring it in your code manually, create a root directory for the
+settings, for example config/opts, and then in it a
+config/opts/opts.rb file with the following contents:
 
-Add the gem to your Gemfile:
+  DynamicConfiguration::create(:Opts, __FILE__)
 
-  gem 'dynamic_configuration'
-
-Create a config/options directory, then a config/options/options.rb
-file with the following contents:
-
-  DynamicConfiguration::create(:Options, File.join(Rails.root, "config/options"))
-
-Require config/options/options.rb somewhere in your
-config/application.rb, like this:
-
-  module SomeApplication
-    class Application < Rails::Application
-      require "config/options/options"
-        
-      # ..., rest of the config
-    end
-  end
-
-### Ruby application:
-
-Create a subdirectory of your project directory where you want to
-store the options, e. g. options/, and put the following before your
-application initialization code:
-
-  DynamicConfiguration::create(:Options, "options/")
+Once you require this file somewhere in your application, the constant
+Opts will hold all the settings.
 
 ## Usage
 
 ### Basics
 
-You create a settings group by creating a file somewhere in the
-options directory, to see how it works, create options/main.rb and
-define a single setting in it:
+You create a settings group by creating a file somewhere in the opts
+directory, for example opts/main.rb, and defining some settings in it,
+using Ruby method call syntax and semantics, but with the name of the
+setting taking the place of the method name:
 
-  # config/options/main.rb
-  a_string "sample value"
+  # config/opts/main.rb
+  owner_email "john@doe.com"
 
-This will make Options.main.a_string evaluate to "sample value"
-anywhere in your application:
+This will make Opts.main.a_string evaluate to "sample value" anywhere
+in your application:
 
-  Options.main.a_string
-  => "sample value"
+  Opts.main.owner_email
+  => "john@doe.com"
 
-The name of the group of options is set to be the same as the base
-name of the file, so if you create emails.rb, the settings will be
-accessible as Options.emails.whatever_you_define etc.
+The name of the group of opts is set to be the same as the base name
+of the file, so if you create emails.rb, the settings will be
+accessible as Opts.emails.whatever_you_define etc.
 
 The value of each settings can be any kind of Ruby object, so the
 following is a valid config file:
 
-  # config/options/main.rb
+  # config/opts/main.rb
   a_string "Some string"
    
   an_array [1, 2, 3]
@@ -93,11 +73,11 @@ following is a valid config file:
 
 Which you can use in other places of your application like this:
 
-  Options.main.a_string
+  Opts.main.a_string
   => "Some string"
-  Options.main.an_array
+  Opts.main.an_array
   => [1, 2, 3]
-  Options.main.a_fancy_string_array
+  Opts.main.a_fancy_string_array
   => ["string1", "string2"]
 
 Note that hash map values have to be wrapped in parenthesis, since
@@ -107,40 +87,56 @@ has to have the syntax of one.
 ### Overriding settings per Rails environment ###
 
 To overwrite the settings for a given Rails environment, just create a
-subdirectory of the options directory named after the name of the
-environment, for example config/options/test/. Then create a file
+subdirectory of the opts directory named after the name of the
+environment, for example config/opts/test/. Then create a file
 corresponding to the group of settings of which one or more you want
-to override. For example, if config/options/main.rb looks like above,
-and you create config/options/test/main.rb looking like this:
+to override. For example, if config/opts/main.rb looks like above, and
+you create config/opts/test/main.rb looking like this:
 
-  # config/options/test/main.rb
+  # config/opts/test/main.rb
   a_string "Test"
 
-Then Options.main.a_string will evaluate to "Test" in the test
-environment, while all the other Options.main settings will evaluate
-to their values defined in config/options/main.rb.
+Then Opts.main.a_string will evaluate to "Test" in the test
+environment, while all the other Opts.main settings will evaluate to
+their values defined in config/opts/main.rb.
 
 ### Overriding settings locally ###
 
 This is mostly meant for applications that are stored in a version
 control system and on which multiple persons work. One can keep the
-core settings in config/options, and also create a
-config/options/local directory, that can be svn ignore'd or added to
-.gitignore. If then someone wants to override some setting just on a
-particular server or just on his local development environment, he/she
-can create a file corresponding to the group of settings of which one
-or more he/she wants to override, for example
-config/options/local/main.rb:
-
-  # config/options/local/main.rb
+default settings in config/opts, and also create a config/opts/local
+directory, that can be ignored in version control. If then someone
+wants to override some setting just on a particular server or just on
+his local development environment, he/she can create a file
+corresponding to the group of settings of which one or more he/she
+wants to override, for example config/opts/local/main.rb:
+
+  # config/opts/local/main.rb
   an_array [4, 5, 6]
 
-Then, Options.main.an_array will evaluate to [4, 5, 6] regardless of
-Rails environment and other Options.main settings will be evaluated
+Then, Opts.main.an_array will evaluate to [4, 5, 6] regardless of
+Rails environment and other Opts.main settings will be evaluated
 according to their per-Rails-environment definitions if present, or
-according to their global definitions in config/options/main.rb
+according to their global definitions in config/opts/main.rb
 otherwise.
 
+## Tips ##
+
+1. Many more obvious constant names like Options, or Config, are names
+of Ruby or Rails classes, and will cause name clashes in certain
+contexts. Hence the examples use less neat but reliable Opts name.
+
+2. You can make the options available much earlier in the Rails
+loading process by explicitly requiring them in config/application.rb:
+
+  module SomeApplication
+    class Application < Rails::Application
+      require "config/opts/opts"
+        
+      # ..., rest of the config
+    end
+  end
+
 ## Robustness ##
 
 dynamic_configuration overwrites method_missing in the context of the

data/README.markdown

@@ -1,25 +1,24 @@
 # dynamic_configuration
 
-Rails made great innovations in almost all areas of web application
-development, yet it surprisingly does not provide any means for
-application configuration, and each of the so far available plugins I
-have seen had some serious disadvantages. Here are the features that
-differentiate dynamic_configuration from other configuration plugins:
+Dynamic_configuration is a library for storing application settings,
+with the following distinguishing characteristics:
 
- * very easy setup with only two lines of code
+ * very easy setup with only one line of code
 
- * configuration files are very clean-looking Ruby files
+ * setting files are neat-looking Ruby files, with all of Ruby
+   available for specifying the setting values
 
- * in Rails development environment, one doesn't have to restart the
-   server to add/remove/modify a setting
+ * settings are divided into groups, each group defined in a separate
+   file, making it easier to remember individual setting names and
+   maintain the whole configuration
 
- * the settings are divided into groups, each group being defined in a
-   separate file, making it easier to remember individual setting
-   names and maintain the whole configuration
+ * settings can be overridden locally for a given installation (useful
+   for customizing webapp configuration per-server, while keeping
+   default developer settings in Git)
 
- * settings can be overridden per-Rails-environment and locally for a
-   given installation (useful for customizing the configuration
-   per-server, while keeping the core settings in Git)
+ * Rails-friendly, for example settings can be overwritten
+   per-Rails-environment, they are also automatically reloaded on
+   every request in Rails development environment
 
  * throughout field- and unit- tested
 
@@ -27,78 +26,53 @@ Developed as part of my work for http://www.tutoria.de/.
 
 ## Setup
 
-### Rails 3 application:
-
-Add the gem to your Gemfile:
-
-```ruby
-gem 'dynamic_configuration'
-```
-
-Create a config/options directory, then a config/options/options.rb
-file with the following contents:
-
-```ruby
-DynamicConfiguration::create(:Options, File.join(Rails.root, "config/options"))
-```
-
-Require config/options/options.rb somewhere in your
-config/application.rb, like this:
+After adding dynamic_configuration to your Gemfile, or installing and
+requiring it in your code manually, create a root directory for the
+settings, for example config/opts, and then in it a
+config/opts/opts.rb file with the following contents:
 
 ```ruby
-module SomeApplication
-  class Application < Rails::Application
-    require "config/options/options"
-        
-    # ..., rest of the config
-  end
-end
+DynamicConfiguration::create(:Opts, __FILE__)
 ```
 
-### Ruby application:
-
-Create a subdirectory of your project directory where you want to
-store the options, e. g. options/, and put the following before your
-application initialization code:
-
-```ruby
-DynamicConfiguration::create(:Options, "options/")
-```
+Once you require this file somewhere in your application, the constant
+Opts will hold all the settings.
 
 ## Usage
 
 ### Basics
 
-You create a settings group by creating a file somewhere in the
-options directory, to see how it works, create options/main.rb and
-define a single setting in it:
+You create a settings group by creating a file somewhere in the opts
+directory, for example opts/main.rb, and defining some settings in it,
+using Ruby method call syntax and semantics, but with the name of the
+setting taking the place of the method name:
 
 ```ruby
-# config/options/main.rb
-a_string "sample value"
+# config/opts/main.rb
+owner_email "john@doe.com"
 ```
 
-This will make Options.main.a_string evaluate to "sample value"
-anywhere in your application:
+This will make Opts.main.a_string evaluate to "sample value" anywhere
+in your application:
 
 ```ruby
-Options.main.a_string
-=> "sample value"
+Opts.main.owner_email
+=> "john@doe.com"
 ```
 
-The name of the group of options is set to be the same as the base
-name of the file, so if you create emails.rb, the settings will be
-accessible as Options.emails.whatever_you_define etc.
+The name of the group of opts is set to be the same as the base name
+of the file, so if you create emails.rb, the settings will be
+accessible as Opts.emails.whatever_you_define etc.
 
 The value of each settings can be any kind of Ruby object, so the
 following is a valid config file:
 
 ```ruby
-# config/options/main.rb
+# config/opts/main.rb
 a_string "Some string"
-
+ 
 an_array [1, 2, 3]
-
+ 
 a_fancy_string_array(%w{
 string1
 string2
@@ -108,11 +82,11 @@ string2
 Which you can use in other places of your application like this:
 
 ```ruby
-Options.main.a_string
+Opts.main.a_string
 => "Some string"
-Options.main.an_array
+Opts.main.an_array
 => [1, 2, 3]
-Options.main.a_fancy_string_array
+Opts.main.a_fancy_string_array
 => ["string1", "string2"]
 ```
 
@@ -123,44 +97,62 @@ has to have the syntax of one.
 ### Overriding settings per Rails environment ###
 
 To overwrite the settings for a given Rails environment, just create a
-subdirectory of the options directory named after the name of the
-environment, for example config/options/test/. Then create a file
+subdirectory of the opts directory named after the name of the
+environment, for example config/opts/test/. Then create a file
 corresponding to the group of settings of which one or more you want
-to override. For example, if config/options/main.rb looks like above,
-and you create config/options/test/main.rb looking like this:
+to override. For example, if config/opts/main.rb looks like above, and
+you create config/opts/test/main.rb looking like this:
 
 ```ruby
-# config/options/test/main.rb
+# config/opts/test/main.rb
 a_string "Test"
 ```
 
-Then Options.main.a_string will evaluate to "Test" in the test
-environment, while all the other Options.main settings will evaluate
-to their values defined in config/options/main.rb.
+Then Opts.main.a_string will evaluate to "Test" in the test
+environment, while all the other Opts.main settings will evaluate to
+their values defined in config/opts/main.rb.
 
 ### Overriding settings locally ###
 
 This is mostly meant for applications that are stored in a version
 control system and on which multiple persons work. One can keep the
-core settings in config/options, and also create a
-config/options/local directory, that can be svn ignore'd or added to
-.gitignore. If then someone wants to override some setting just on a
-particular server or just on his local development environment, he/she
-can create a file corresponding to the group of settings of which one
-or more he/she wants to override, for example
-config/options/local/main.rb:
+default settings in config/opts, and also create a config/opts/local
+directory, that can be ignored in version control. If then someone
+wants to override some setting just on a particular server or just on
+his local development environment, he/she can create a file
+corresponding to the group of settings of which one or more he/she
+wants to override, for example config/opts/local/main.rb:
 
 ```ruby
-# config/options/local/main.rb
+# config/opts/local/main.rb
 an_array [4, 5, 6]
 ```
 
-Then, Options.main.an_array will evaluate to [4, 5, 6] regardless of
-Rails environment and other Options.main settings will be evaluated
+Then, Opts.main.an_array will evaluate to [4, 5, 6] regardless of
+Rails environment and other Opts.main settings will be evaluated
 according to their per-Rails-environment definitions if present, or
-according to their global definitions in config/options/main.rb
+according to their global definitions in config/opts/main.rb
 otherwise.
 
+## Tips ##
+
+1. Many more obvious constant names like Options, or Config, are names
+of Ruby or Rails classes, and will cause name clashes in certain
+contexts. Hence the examples use less neat but reliable Opts name.
+
+2. You can make the options available much earlier in the Rails
+loading process by explicitly requiring them in config/application.rb:
+
+```ruby
+module SomeApplication
+  class Application < Rails::Application
+    require "config/opts/opts"
+      
+    # ..., rest of the config
+  end
+end
+```
+
 ## Robustness ##
 
 dynamic_configuration overwrites method_missing in the context of the
@@ -174,4 +166,4 @@ accidentally modify them. If you try to access a settings group that
 wasn't defined, you will get an
 DynamicConfiguration::MissingGroupException, if you try to access a
 setting that isn't defined of a group that _is_ defined, you will get
-a DynamicConfiguration::MissingSettingException.
+a DynamicConfiguration::MissingGroupException.

data/VERSION

@@ -1 +1 @@
-0.3.14
+0.3.15

data/dynamic_configuration.gemspec

@@ -2,11 +2,11 @@
 # DO NOT EDIT THIS FILE DIRECTLY
 # Instead, edit Jeweler::Tasks in Rakefile, and run 'rake gemspec'
 # -*- encoding: utf-8 -*-
-# stub: dynamic_configuration 0.3.14 ruby lib
+# stub: dynamic_configuration 0.3.15 ruby lib
 
 Gem::Specification.new do |s|
   s.name = "dynamic_configuration"
-  s.version = "0.3.14"
+  s.version = "0.3.15"
 
   s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version=
   s.require_paths = ["lib"]

data/lib/railtie.rb

@@ -1,7 +1,9 @@
 class DynamicConfigurationRailtie < Rails::Railtie
   config.to_prepare do
-    DynamicConfiguration.const_names.each do |const_name|
-      Object.send(:remove_const, const_name) if Object.const_defined?(const_name)
+    if Rails.env == 'development'
+      DynamicConfiguration.const_names.each do |const_name|
+        Object.send(:remove_const, const_name) if Object.const_defined?(const_name)
+      end
     end
   end
 

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: dynamic_configuration
 version: !ruby/object:Gem::Version
-  version: 0.3.14
+  version: 0.3.15
 platform: ruby
 authors:
 - Jarosław Rzeszótko