aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRyan Bigg <radarlistener@gmail.com>2010-11-29 14:10:36 +1100
committerRyan Bigg <radarlistener@gmail.com>2010-11-29 14:10:36 +1100
commit390de62cacb6b3c89916b1146cdf204a5bab0703 (patch)
treec0ef3d883a6b1c3aa1a4bafde1d58f02ef461a3a
parent685353afc7ddfd58ce99249763a2c08d44d4df5c (diff)
downloadrails-390de62cacb6b3c89916b1146cdf204a5bab0703.tar.gz
rails-390de62cacb6b3c89916b1146cdf204a5bab0703.tar.bz2
rails-390de62cacb6b3c89916b1146cdf204a5bab0703.zip
Fix documentation regarding the initialization events of the Rails stack
-rw-r--r--railties/guides/source/configuring.textile23
1 files 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.
-<ruby>
-config.after_initialize do
- SomeClass.init
-end
-</ruby>
+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