From 390de62cacb6b3c89916b1146cdf204a5bab0703 Mon Sep 17 00:00:00 2001 From: Ryan Bigg Date: Mon, 29 Nov 2010 14:10:36 +1100 Subject: [PATCH] Fix documentation regarding the initialization events of the Rails stack --- railties/guides/source/configuring.textile | 23 ++++++++++------------ 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/railties/guides/source/configuring.textile b/railties/guides/source/configuring.textile index 38226e750a..3a49d42aaf 100644 --- a/railties/guides/source/configuring.textile +++ b/railties/guides/source/configuring.textile @@ -316,25 +316,22 @@ There are a few configuration options available in Active Support: * +ActiveSupport::Logger.silencer+ is set to +false+ to disable the ability to silence logging in a block. The default is +true+. -h3. Using Initializers +h3. Initialization events -After loading the framework and any gems and plugins in your application, Rails turns to loading initializers. An initializer is any file of Ruby code stored under +config/initializers+ in your application. You can use initializers to hold configuration settings that should be made after all of the frameworks and plugins are loaded. - -NOTE: You can use subfolders to organize your initializers if you like, because Rails will look into the whole file hierarchy from the +initializers+ folder on down. +Rails has 4 initialization events which can be hooked into (listed in order that they are ran): -TIP: If you have any ordering dependency in your initializers, you can control the load order by naming. For example, +01_critical.rb+ will be loaded before +02_normal.rb+. +* +before_configuration+: This is run as soon as the application constant inherits from +Rails::Application+. The +config+ calls are evaluated before this happens. +* +before_eager_load+: This is run directly before eager loading occurs, which is the default behaviour for the _production_ environment and not for the +development+ enviroment. +* +before_initialize+ This is run directly before the initialization process of the application occurs. +* +after_initialize+ Run directly after the initialization of the application, but before the application initializers are run. -h3. Using an After-Initializer +WARNING: Some parts of your application, notably observers and routing, are not yet set up at the point where the +after_initialize+ block is called. -After-initializers are run (as you might guess) after any initializers are loaded. You can supply an +after_initialize+ block (or an array of such blocks) by setting up +config.after_initialize+ in any of the Rails configuration files: +After loading the framework and any gems and plugins in your application, Rails turns to loading initializers. An initializer is any file of Ruby code stored under +config/initializers+ in your application. You can use initializers to hold configuration settings that should be made after all of the frameworks and plugins are loaded. - -config.after_initialize do - SomeClass.init -end - +NOTE: You can use subfolders to organize your initializers if you like, because Rails will look into the whole file hierarchy from the +initializers+ folder on down. -WARNING: Some parts of your application, notably observers and routing, are not yet set up at the point where the +after_initialize+ block is called. +TIP: If you have any ordering dependency in your initializers, you can control the load order by naming. For example, +01_critical.rb+ will be loaded before +02_normal.rb+. h3. Rails Environment Settings -- GitLab