Every major component of Rails (Action Mailer, Action Controller, Active Record, etc.) implements a railtie. Each of them is responsible for their own initialization. This makes Rails itself absent of any component hooks, allowing other components to be used in place of any of the Rails defaults.
For example, an extension doing any of the following would need a railtie:
configuring a Rails framework for the application, like setting a generator
config.* keys to the environment
setting up a subscriber with
adding Rake tasks
The following example demonstrates an extension which can be used with or without Rails.
# lib/my_gem/railtie.rb module MyGem class Railtie < Rails::Railtie end end # lib/my_gem.rb require 'my_gem/railtie' if defined?(Rails)
To add an initialization step to the Rails boot process from your railtie, just define the initialization code with the
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, like middleware:
class MyRailtie < Rails::Railtie initializer "my_railtie.configure_rails_initialization" do |app| app.middleware.use MyRailtie::Middleware end end
Finally, you can also pass
:after as options to
initializer, in case you want to couple it with a specific step in the initialization process.
Railties can access a config object which contains configuration shared by all railties and the application:
class MyRailtie < Rails::Railtie # Customize the ORM config.app_generators.orm :my_railtie_orm # Add a to_prepare block which is executed once in production # and before each request in development. config.to_prepare do MyRailtie.setup! end end
If your railtie has Rake tasks, you can tell Rails to load them through the method
class MyRailtie < Rails::Railtie rake_tasks do load 'path/to/my_railtie.tasks' end end
By default, Rails loads 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 < Rails::Railtie generators do require 'path/to/my_railtie_generator' end end
An engine is nothing more than a railtie with some initializers already set. And since
Rails::Application is an engine, the same configuration described here can be used in both.
Be sure to look at the documentation of those specific classes for more information.
# File railties/lib/rails/railtie.rb, line 150 def abstract_railtie? ABSTRACT_RAILTIES.include?(name) end
Allows you to configure the railtie. This is the same method seen in Railtie::Configurable, but this module is no longer required for all subclasses of Railtie so we provide the class method here.
# File railties/lib/rails/railtie.rb, line 172 def configure(&block) instance.configure(&block) end
# File railties/lib/rails/railtie.rb, line 138 def console(&blk) register_block_for(:load_console, &blk) end
# File railties/lib/rails/railtie.rb, line 146 def generators(&blk) register_block_for(:generators, &blk) end
# File railties/lib/rails/railtie.rb, line 128 def inherited(base) unless base.abstract_railtie? subclasses << base end end
# File railties/lib/rails/railtie.rb, line 154 def railtie_name(name = nil) @railtie_name = name.to_s if name @railtie_name ||= generate_railtie_name(self.name) end
# File railties/lib/rails/railtie.rb, line 134 def rake_tasks(&blk) register_block_for(:rake_tasks, &blk) end
# File railties/lib/rails/railtie.rb, line 165 def respond_to_missing?(*args) instance.respond_to?(*args) || super end
# File railties/lib/rails/railtie.rb, line 142 def runner(&blk) register_block_for(:runner, &blk) end
# File railties/lib/rails/railtie.rb, line 124 def subclasses @subclasses ||=  end
© 2004–2017 David Heinemeier Hansson
Licensed under the MIT License.