Created Feb 2, 2010

Railtie is the core of the Rails Framework and provides several hooks to
extend Rails and/or modify the initialization process.

Every major component of Rails (Action Mailer, Action Controller, Action
View, Active Record and Active Resource) are all Railties, so each of them
is responsible to set their own initialization. This makes, for example,
Rails absent of any ActiveRecord hook, allowing any other ORM to hook in.

Developing a Rails extension does not require any implementation
of Railtie, but if you need to interact with the Rails framework during
boot, or after boot, then Railtie is what you need to do that interaction.

For example, the following would need you to implement Railtie in your
plugin:

creating initializers

configuring a Rails framework or the Application, like setting a generator

adding Rails config.* keys to the environment

setting up a subscriber to the Rails +ActiveSupport::Notifications+

adding rake tasks into rails

Creating your Railtie

Implementing Railtie in your Rails extension is done by creating a class
Railtie that has your extension name and making sure that this gets loaded
during boot time of the Rails stack.

You can do this however you wish, but here is an example if you want to
provide it for a gem that can be used with or without Rails:

Create a file (say, lib/my_gem/railtie.rb) which contains class Railtie
inheriting from Rails::Railtie and is namespaced to your gem:

Initializers

To add an initialization step from your Railtie to Rails boot process, you
just need to create an initializer block:

class MyRailtie < Rails::Railtie
initializer "my_railtie.configure_rails_initialization" do
# some initialization behavior
end
end

If specified, the block can also receive the application object, in case
you need to access some application specific configuration:

class MyRailtie < Rails::Railtie
initializer "my_railtie.configure_rails_initialization" do |app|
if app.config.cache_classes
# some initialization behavior
end
end
end

Finally, you can also pass :before and :after as option to initializer, in
case you want to couple it with a specific step in the initialization
process.

Configuration

Inside the Railtie class, you can access a config object which contains
configuration shared by all railties and the application:

class MyRailtie < Rails::Railtie
# Customize the ORM
config.generators.orm :my_railtie_orm
# Add a middleware
config.middlewares.use MyRailtie::Middleware
# Add a to_prepare block which is executed once in production
# and before which request in development
config.to_prepare do
MyRailtie.setup!
end
end

Loading rake tasks and generators

If your railtie has rake tasks, you can tell Rails to load them through the
method rake tasks:

class MyRailtie < Railtie
rake_tasks do
load "path/to/my_railtie.tasks"
end
end

By default, Rails load generators from your load path. However, if you want
to place your generators at a different location, you can specify in your
Railtie a block which will load them during normal generators lookup:

class MyRailtie < Railtie
generators do
require "path/to/my_railtie_generator"
end
end

Adding your subscriber

Since version 3.0, Rails ships with a notification system which is used for
several purposes, including logging. If you are sending notifications in
your Railtie, you may want to add a subscriber to consume such
notifications for logging purposes.

The subscriber is added under the railtie_name namespace and only consumes
notifications under the given namespace. For example, let's suppose
your railtie is publishing the following “something_expensive”
instrumentation:

Application, Plugin and Engine

A Rails::Engine is nothing more than a Railtie with some initializers
already set. And since Rails::Application and Rails::Plugin are engines,
the same configuration described here can be used in all three.

Be sure to look at the documentation of those specific classes for more
information.

Rails::Engine allows you to wrap a specific Rails application and share it
accross different applications. Since Rails 3.0, your Rails::Application is
nothing more than an Engine, thus your engines will behave much more closer
to an application since then.

Any Rails::Engine is also a Rails::Railtie, so the same methods (like
rake_tasks and generators) and configuration available in the latter can
also be used in the former.

Creating an Engine

In Rails versions before to 3.0, your gems automatically behaved as Engine,
however this coupled Rails to Rubygems. Since Rails 3.0, if you want a gem
to automatically behave as Engine, you have to specify an Engine for it
somewhere inside your plugin lib folder (similar with how we spceify a
Railtie):

Then ensure that this file is loaded at the top of your
config/application.rb (or in your Gemfile) and it will automatically load
models, controllers, helpers and metals inside app, load routes at
“config/routes.rb”, load locales at “config/locales/*”, load tasks at
“lib/tasks/*”.

Configuration

Besides the Railtie configuration which is shared across the application,
in a Rails::Engine you can access load_paths, eager_load_paths and
load_once_paths, which differently from a Railtie, are scoped to the
current Engine.

Paths

Since Rails 3.0, both your Application and Engines does not have hardcoded
paths. This means that you are not required to place your controllers at
“app/controllers”, but in any place which you find convenient.

For example, let's suppose you want to lay your controllers at
lib/controllers, all you need to do is:

Your Application class adds a couple more paths to this set. And as in your
Application, all folders under “app” are automatically added to the load
path. So if you have “app/observers”, it's added by default.

Rails::Plugin is nothing more than a Rails::Engine, but since it's
loaded too late in the boot process, it does not have the same
configuration powers as a bare Rails::Engine.

Opposite to Rails::Railtie and Rails::Engine, you are not supposed to
inherit from Rails::Plugin. Rails::Plugin is automatically configured to be
an engine by simply placing inside vendor/plugins. Since this is done
automatically, you actually cannot declare a Rails::Engine inside your
Plugin, otherwise it would cause the same files to be loaded twice. This
means that if you want to ship an Engine as gem it cannot be used as plugin
and vice-versa.

Besides this conceptual difference, the only difference between
Rails::Engine and Rails::Plugin is that plugins automatically load the file
“init.rb” at the plugin root during the boot process.

In Rails 3.0, a Rails::Application object was introduced which is nothing
more than an Engine but with the responsibility of coordinating the whole
boot process.

Opposite to Rails::Engine, you can only have one Rails::Application
instance in your process and both Rails::Application and
YourApplication::Application points to it.

In other words, Rails::Application is Singleton and whenever you are
accessing Rails::Application.config or YourApplication::Application.config,
you are actually accessing YourApplication::Application.instance.config.

Initialization

Rails::Application is responsible for executing all railties, engines and
plugin initializers. Besides, it also executed some bootstrap initializers
(check Rails::Application::Bootstrap) and finishing initializers, after all
the others are executed (check Rails::Application::Finisher).

Configuration

Besides providing the same configuration as Rails::Engine and
Rails::Railtie, the application object has several specific configurations,
for example “allow_concurrency”, “cache_classes”,
“consider_all_requests_local”, “filter_parameters”, “logger”, “metals”,
“reload_engines”, “reload_plugins” and so forth.

Check Rails::Application::Configuration to see them all.

Routes

The application object is also responsible for holding the routes and
reloading routes whenever the files change in development.

Middlewares and metals

The Application is also responsible for building the middleware stack and
setting up both application and engines metals.