Rails applications' life cycle

Question

I'm trying to learn the life cycle of a rails application. When is application_controller.rb run? Is it just once every time it's changed, or on every request?

I want to know the same about the following file:

• config/environments/*.rb (development, production, or test, depending on the current mode)
• boot.rb
• environment.rb
• routes.rb

One of the reasons I'm asking this is, I want to know where is a good place to put

• initialization code
• custom configuration data

EDIT:

@Gdeglin's answer is good, but I'm actually interested in knowing when each of these files run.

Answer 1

application_controller.rb

ApplicationController is a parent class to all controllers. Methods declared in it will be available to all controllers for this reason.

ApplicationController is a convenient place to filters that you want to apply to all controllers in your application, or methods that you wish to make available to all of them.

config/environments/*.rb

The files in config/environments/*.rb override settings in the default config/enviornment.rb file depending on what environment your server is running in (development/production). One example is that in development errors are printed to the screen and in production a generic error page is returned. This setting is in config/environments/development.rb

boot.rb

boot.rb is used as part of the rails initialization process. You usually don't need to, and likely shouldn't touch it.

environment.rb

environment.rb is the generic configuration file for your application.

routes.rb

routes.rb is used to define how your application handles requests to specific urls. For example, you may want to have all 404 requests go to a specific action instead of being handled by the default error handler:

map.connect '*path', :controller => 'home', :action => 'on_404' 

It is also an important part of implementing a RESTful application.

Where to place initialization & configuration code

Both initialization code and custom configuration data should be placed in enviornment.rb (read the comments in this file). If you want certain code to run during initialization only in development or only in production, place it in config/environments/development.rb or config/environments/production.rb respectively.

Edit:

A good overview on when each of these files is run during initialization is available here:

http://toolmantim.com/articles/environments_and_the_rails_initialisation_process https://github.com/toolmantim/toolmantim/blob/master/articles/environments_and_the_rails_initialisation_process.haml

Essentially the steps are:

1. The Rails Initializer is loaded (http://api.rubyonrails.org/classes/Rails/Initializer.html)

2. The rails Initializer sets up logging and then loads environment.rb

3. environment.rb loads boot.rb

4. boot.rb sets the RAILS_ROOT constant and adds rails libraries and application code to the LOAD_PATH

5. environment.rb executes Rails::Initializer.run.

6. The rails framework is loaded (ActiveRecord, ActionMailer, etc.)

7. Your environment's specific config file is loaded (config/environments/development.rb.)

8. after_initialize and to_prepare callbacks are executed if you have created any

9. Rails has finished loading and is ready to handle requests

Answer 2

With a little effort, you can follow it through yourself, which will probably be more useful.

Start from 'ruby script/server'. In my (2.1) application, that look for a file named "server" in the "script" directory. It contains this:

#!/usr/bin/env ruby require File.dirname(__FILE__) + '/../config/boot' require 'commands/server' 

So it requires boot.rb, which defines a whole lot of stuff and then calls Rails.boot! which more or less runs any pre-initialization you've defined and then requires environment, which does another level of bootstrapping. By that time it's starting to get complicated: I'd recommend a large-ish sheet of paper...

And so on.

Alternatively, you may be able to hack Kernel#require to log when a file is being required in - I haven't tried it myself (and the method may be overridden elsewhere) but it could work...

application_controller isn't exactly "run" at all - it's a parent class for your other controllers, so its content, if required and not overridden becomes available when the inheriting controller is loaded. You'd generally use it to provide common functionality across all your controllers.