This guide explains how the initialization process in Rails works as of Rails 3.
- Using rails server
- Using Passenger
endprologue.
This guide first describes the process of rails server then explains the Passenger + Rack method, before delving into the common initialize pattern these two go through.
As of Rails 3, script/server has become rails server. This was done to centralise all rails related commands to one common file.
The actual rails command is kept in railties/bin/rails and goes like this:
require ‘rbconfig’ module Rails module ScriptRailsLoader RUBY = File.join(*RbConfig::CONFIG.values_at(“bindir”, “ruby_install_name”)) + RbConfig::CONFIG[“EXEEXT”] SCRIPT_RAILS = File.join(‘script’, ‘rails’) def self.exec_script_rails! cwd = Dir.pwd exec RUBY, SCRIPT_RAILS, *ARGV if File.exists?(SCRIPT_RAILS) Dir.chdir(“..”) do- Recurse in a chdir block: if the search fails we want to be sure
- the application is generated in the original working directory.
exec_script_rails! unless cwd == Dir.pwd
end
rescue SystemCallError - could not chdir, no problem just return
end
end
end
The Rails::ScriptRailsLoader module here defines two constants: RUBY and SCRIPT_RAILS. RUBY is the full path to your ruby executable, on a Snow Leopard system it’s /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby_. +SCRIPTRAILS+ is simply script/rails_. When +exec_scriptrails+ is invoked, this will attempt to exec the rails file in the script directory using the path to your Ruby executable, RUBY. If exec is invoked, the program will stop at this point. If the script/rails file doesn’t exist in the current directory, Rails will recurse upwards until it finds it by calling exec_script_rails from inside the Dir.chdir(“..”). This is handy if you’re currently in one of the sub-directories of the rails application and wish to launch a server or a console.
If Rails cannot execute script/rails then it will fall back to the standard rails command task of generating an application.
In script/rails we see the following:
#!/usr/bin/env ruby- This command will automatically be run when you run “rails” with Rails 3 gems installed from the root of your application.
This obviously defines a couple of constants to some pretty important files, config/environment.rb, config/boot.rb and config/application.rb all within the context of FILE which is of course script/rails in the root of your application. Then it goes on to require BOOT_PATH which leads us onto config/boot.rb.
Before we dive into what config/boot.rb encompasses, we’ll just glimpse at what Passenger does enough to get an understanding of how it requires a Rails application.
Passenger will require config/environment.rb by way of its PhusionPassenger::Railz::ApplicationSpawner#preload_application method. config/environment.rb requires config/application.rb which requires config/boot.rb. That’s how the Rails boot process begins with Passenger in a nutshell.
config/boot.rb is the first stop for everything for initializing your application. This boot process does quite a bit of work for you and so this section attempts to go in-depth enough to explain what each of the pieces does.
- Use Bundler (preferred)
begin
require File.expand_path(‘../../.bundle/environment’, FILE)
rescue LoadError
require ‘rubygems’
require ‘bundler’
Bundler.setup
end
Rails 3 now uses Bundler and the README for the project explains it better than I could:
> “Bundler is a tool that manages gem dependencies for your ruby application. It takes a gem manifest file and is able to fetch, download, and install the gems and all child dependencies specified in this manifest. It can manage any update to the gem manifest file and update the bundle’s gems accordingly. It also lets you run any ruby code in context of the bundle’s gem environment.”
Now with Rails 3 we have a Gemfile which defines the basics our application needs to get going:
source ‘http://rubygems.org’ gem ‘rails’, ‘3.0.0.beta1’- Bundle edge Rails instead:
- gem ‘rails’, :git => ‘git://github.com/rails/rails.git’
- Use unicorn as the web server
- gem ‘unicorn’
- Deploy with Capistrano
- gem ‘capistrano’
- Bundle the extra gems:
- gem ‘bj’
- gem ‘nokogiri’, ‘1.4.1’
- gem ‘sqlite3-ruby’, :require => ‘sqlite3’
- gem ‘aws-s3’, :require => ‘aws/s3’
- Bundle gems for certain environments:
- gem ‘rspec’, :group => :test
- group :test do
- gem ‘webrat’
- end
Here the only two gems we need are rails and sqlite3-ruby, so it seems. This is until you run bundle pack. This command freezes all the gems required by your application into vendor/cache. The gems installed by default are:
- abstract-1.0.0.gem
- actionmailer-3.0.0.beta1.gem
- actionpack-3.0.0.beta1.gem
- activemodel-3.0.0.beta1.gem
- activerecord-3.0.0.beta1.gem
- activeresource-3.0.0.beta1.gem
- activesupport-3.0.0.beta1.gem
- arel-0.3.3.gem
- builder-2.1.2.gem
- bundler-0.9.14.gem
- erubis-2.6.5.gem
- i18n-0.3.6.gem
- mail-2.1.5.3.gem
- memcache-client-1.8.1.gem
- mime-types-1.16.gem
- polyglot-0.3.1.gem
- rack-1.1.0.gem
- rack-mount-0.6.3.gem
- rack-test-0.5.3.gem
- rails-3.0.0.beta1.gem
- railties-3.0.0.beta1.gem
- rake-0.8.7.gem
- sqlite3-ruby-1.2.5.gem
- text-format-1.0.0.gem
- text-hyphen-1.0.0.gem
- thor-0.13.4.gem
- treetop-1.4.5.gem
- tzinfo-0.3.18.gem
TODO: Prettify when it becomes more stable.
I won’t go into what each of these gems are, as that is really something that needs covering on a case-by-case basis. We will however just dig a little under the surface of Bundler.
Back in config/boot.rb, the first line will try to include .bundle/environment.rb, which doesn’t exist in a bare-bones Rails application and because this file does not exist Ruby will raise a LoadError which will be rescued and run the following code:
require ‘rubygems’ require ‘bundler’ Bundler.setupBundler.setup here will load and parse the Gemfile and add the lib directory of the gems mentioned and their dependencies (and their dependencies’ dependencies, and so on) to the $LOAD_PATH.
Now we will go down the alternate timeline where we generate a .bundle/environment.rb file using the bundle lock command. This command also creates a Gemfile.lock file which is actually a YAML file loaded by this method in Bundler before it moves on to check for Gemfile:
def definition(gemfile = default_gemfile) configure root = Pathname.new(gemfile).dirname lockfile = root.join(“Gemfile.lock”) if lockfile.exist? Definition.from_lock(lockfile) else Definition.from_gemfile(gemfile) end endThe .bundle/environment.rb file adds the lib directory of all the gems specified in Gemfile.lock to $LOAD_PATH.
After config/boot.rb is loaded, there’s this require:
require ‘rails/commands’In this file, railties/lib/rails/commands.rb, there is a case statement for ARGV.shift:
case ARGV.shift … when ‘s’, ‘server’ require ‘rails/commands/server’- Initialize the server first, so environment options are set
server = Rails::Server.new
require APP_PATH
…
end
We’re running rails server and this means it will make a require out to rails/commands/server (railties/lib/rails/commands/server.rb). Firstly, this file makes a couple of requires of its own:
require ‘fileutils’ require ‘optparse’ require ‘action_dispatch’The first two are Ruby core and this guide does not cover what they do, but action_dispatch (actionpack/lib/action_dispatch.rb) is important. This file firstly make a require to active_support (activesupport/lib/active_support.rb) which defines the ActiveSupport module.
activesupport/lib/active_support.rb sets up module ActiveSupport:
module ActiveSupport class << self attr_accessor :load_all_hooks def on_load_all(&hook) load_all_hooks << hook end def load_all!; load_all_hooks.each { |hook| hook.call } end end self.load_all_hooks = [] on_load_all do [Dependencies, Deprecation, Gzip, MessageVerifier, Multibyte, SecureRandom] end endThis defines two methods on the module itself by using the familiar class << self syntax. This allows you to call them as if they were class methods: ActiveSupport.on_load_all and ActiveSupport.load_all! respectively. The first method simply adds loading hooks to save them up for loading later on when load_all! is called. By +call+’ing the block, the classes will be loaded. (NOTE: kind of guessing, I feel 55% about this).
The on_load_all method is called later with the Dependencies, Deprecation, Gzip, MessageVerifier, Multibyte and SecureRandom. What each of these modules do will be covered later.
This file goes on to define some classes that will be automatically loaded using Ruby’s autoload method, but not before including Rails’s own variant of the autoload method from active_support/dependencies/autoload.rb:
require “active_support/inflector/methods” require “active_support/lazy_load_hooks” module ActiveSupport module Autoload def self.extended(base) base.extend(LazyLoadHooks) end @@autoloads = {} @@under_path = nil @@at_path = nil @@eager_autoload = false def autoload(const_name, path = @@at_path) full = [self.name, @@under_path, const_name.to_s, path].compact.join(“::”) location = path || Inflector.underscore(full) if @@eager_autoload @@autoloads[const_name] = location end super const_name, location end … end endAt the top if the ActiveSupport::Autoload module is the def self.extended method:
def self.extended(base) base.extend(LazyLoadHooks) endThis is called when we extend this module into one of our classes or modules, such is the case later on when we call extend ActiveSupport::LazyLoadHooks not only in the ActiveSupport module, but in all of the Railtie modules (ActiveRecord and so on), as well as in a couple of places.
ActiveSupport::LazyLoadHooks is responsible for defining methods used for running hooks that are defined during the initialization process, such as the one defined inside the active_record.initialize_timezone initializer:
initializer “active_record.initialize_timezone” do ActiveRecord.base_hook do self.time_zone_aware_attributes = true self.default_timezone = :utc end endWhen the initializer is ran it defines a base_hook for ActiveRecord and will only run it when run_base_hooks is called, which in the case of Active Record, is ran after the entirety of activerecord/lib/active_record/base.rb has been evaluated.
This file also uses the method eager_autoload also defined in active_support/dependencies/autoload.rb:
def eager_autoload old_eager,@eager_autoload = @eager_autoload, true
yield
ensure
@@eager_autoload = old_eager
end
As you can see for the duration of the eager_autoload block the class variable @@eager_autoload is set to true, which has the consequence of when autoload is called that the location of the file for that specific +autoload+’d constant is added to the @@autoloads hash initialized at the beginning of this module declaration. So now that you have part of the context, here’s the other, the code from activesupport/lib/active_support.rb:
require “active_support/dependencies/autoload” module ActiveSupport extend ActiveSupport::Autoload- TODO: Narrow this list down
eager_autoload do
autoload :BacktraceCleaner
autoload :Base64
autoload :BasicObject
autoload :Benchmarkable
autoload :BufferedLogger
autoload :Cache
autoload :Callbacks
autoload :Concern
autoload :Configurable
autoload :Deprecation
autoload :Gzip
autoload :Inflector
autoload :JSON
autoload :Memoizable
autoload :MessageEncryptor
autoload :MessageVerifier
autoload :Multibyte
autoload :OptionMerger
autoload :OrderedHash
autoload :OrderedOptions
autoload :Notifications
autoload :Rescuable
autoload :SecureRandom
autoload :StringInquirer
autoload :XmlMini
end
So we know the ones in eager_autoload are eagerly loaded and it does this by storing them in an @@autoloads hash object and then loading them via eager_autoload! which is called via the preload_frameworks initializer defined in railties/lib/rails/application/bootstrap.rb.
The classes and modules that are not +eager_autoload+’d are automatically loaded as they are references
Note: What does it means to be autoloaded? An example of this would be calling the ActiveSupport::TestCase class which hasn’t yet been initialized. Because it’s been specified as an autoload Ruby will require the file that it’s told to. The file it requires is not defined in the autoload call here but, as you may have seen, in the ActiveSupport::Autoload.autoload definition. So once that file has been required Ruby will try again and then if it still can’t find it it will throw the all-too-familiar uninitialized constant error.
Back in actionpack/lib/action_dispatch.rb, the next require after active_support is to active_support/dependencies/autoload but this file has already been loaded by activesupport/lib/active_support.rb and so will not be loaded again. The next require is to Rack itself:
require ‘rack’As mentioned previously, Bundler has added the gems’ lib directories to the load path so this rack file that is referenced lives in the Rack gem: lib/rack.rb. This loads Rack so we can use it later on when we define Rails::Server to descend from Rack::Server.
This file then goes on to define the ActionDispatch module and it’s related autoloads:
module Rack autoload :Test, ‘rack/test’ end module ActionDispatch extend ActiveSupport::Autoload autoload_under ‘http’ do autoload :Request autoload :Response end autoload_under ‘middleware’ do autoload :Callbacks autoload :Cascade autoload :Cookies autoload :Flash autoload :Head autoload :ParamsParser autoload :RemoteIp autoload :Rescue autoload :ShowExceptions autoload :Static end autoload :MiddlewareStack, ‘action_dispatch/middleware/stack’ autoload :Routing module Http extend ActiveSupport::Autoload autoload :Cache autoload :Headers autoload :MimeNegotiation autoload :Parameters autoload :FilterParameters autoload :Upload autoload :UploadedFile, ‘action_dispatch/http/upload’ autoload :URL end module Session autoload :AbstractStore, ‘action_dispatch/middleware/session/abstract_store’ autoload :CookieStore, ‘action_dispatch/middleware/session/cookie_store’ autoload :MemCacheStore, ‘action_dispatch/middleware/session/mem_cache_store’ end autoload_under ‘testing’ do autoload :Assertions autoload :Integration autoload :PerformanceTest autoload :TestProcess autoload :TestRequest autoload :TestResponse end end autoload :Mime, ‘action_dispatch/http/mime_type’Now that Rails has required Action Dispatch and it has required Rack, Rails can now go about defining the Rails::Server class:
module Rails class Server < ::Rack::Server … def initialize(*) super set_environment end … def set_environment ENV[“RAILS_ENV”] ||= options[:environment] end … end endBack in rails/commands Rails calls Rails::Server.new which calls the initialize method on the Rails::Server class, which calls super, meaning it’s actually calling Rack::Server#initialize, with it being defined like this:
def initialize(options = nil) @options = options endThe options method like this:
def options @options ||= parse_options(ARGV) endThe parse_options method like this:
def parse_options(args) options = default_options- Don’t evaluate CGI ISINDEX parameters.
- http://hoohoo.ncsa.uiuc.edu/cgi/cl.html
args.clear if ENV.include?(“REQUEST_METHOD”)
And default_options like this:
def default_options { :environment => “development”, :pid => nil, :Port => 9292, :Host => “0.0.0.0”, :AccessLog => [], :config => “config.ru” } endHere it is important to note that the default environment is development_. After Rack::Server#initialize has done its thing it returns to Rails::Server#initialize which calls +setenvironment+:
def set_environment ENV[“RAILS_ENV”] ||= options[:environment] endFrom the information given we can determine that ENV[“RAILS_ENV”] will be set to development if no other environment is specified.
Finally, after Rails::Server.new has executed, there is one more require:
require APP_PATHAPP_PATH was previously defined as config/application.rb in the application’s root, and so that is where Rails will go next.
This file is config/application.rb in your application and makes two requires to begin with:
require File.expand_path(‘../boot’, FILE) require ‘rails/all’The ../boot file it references is config/boot.rb, which was loaded earlier in the initialization process and so will not be loaded again.
If you generate the application with the -O option this will put a couple of pick-and-choose requirements at the top of your config/application.rb instead:
- Pick the frameworks you want:
- require “active_record/railtie”
require “action_controller/railtie”
require “action_mailer/railtie”
require “active_resource/railtie”
require “rails/test_unit/railtie”
For the purposes of this guide, will will assume only:
require ‘rails/all’Now we’ll dive into the internals of the pre-initialization stage of Rails. The file that is being required is railties/lib/rails/all.rb. The first line in this file is:
require ‘rails’This file (railties/lib/rails.rb) requires the very, very basics that Rails needs to get going. I’m not going to delve into these areas yet, just cover them briefly for now. Later on we will go through the ones that are important to the boot procedure.
require ‘pathname’ require ‘active_support’ require ‘active_support/core_ext/kernel/reporting’ require ‘active_support/core_ext/logger’ require ‘rails/application’ require ‘rails/version’ require ‘rails/deprecation’ require ‘rails/log_subscriber’ require ‘rails/ruby_version_check’ require ‘active_support/railtie’ require ‘action_dispatch/railtie’require ‘pathname’ requires the Pathname class which is used for returning a Pathname object for Rails.root so that instead of doing:
File.join(Rails.root, “app/controllers”)You may do:
Rails.root.join(“app/controllers”)Although this is not new to Rails 3 (it was available in 2.3.5), it is something worthwhile pointing out.
Inside this file there are other helpful helper methods defined, such as Rails.root, Rails.env, Rails.logger and Rails.application.
The first require:
require ‘active_support’Is not ran as this was already required by actionpack/lib/action_dispatch.rb.
This file extends the Kernel module, providing the methods silence_warnings, enable_warnings, with_warnings, silence_stderr, silence_stream and suppress. The API documentation on these overridden methods is fairly good and if you wish to know more have a read.
For information on this file see the “Core Extensions” guide. TODO: link to guide.
For information on this file see the “Core Extensions” guide. TODO: link to guide.
Here’s where Rails::Application is defined. This is the superclass of YourApp::Application from config/application.rb and the subclass of Rails::Engine This is the main entry-point into the Rails initialization process as when your application is initialized, your class is the basis of its configuration.
This file requires three important files before Rails::Application is defined: rails/railties_path.rb, rails/plugin.rb and rails/engine.rb.
This file serves one purpose:
RAILTIES_PATH = File.expand_path(File.join(File.dirname(FILE), ‘..’, ‘..’))Helpful, hey? One must wonder why they just didn’t define it outright.
Firstly this file requires rails/engine.rb, which defines our Rails::Engine class, explained in the very next section.
This file defines a class called Rails::Plugin which descends from Rails::Engine.
This defines the first few initializers for the Rails stack:
- load_init_rb
- sanity_check_railties_collisons
These are explained in the Initialization section. TODO: First write initialization section then come back here and link.
TODO: Expand.
This file requires rails/railtie.rb which defines Rails::Railtie.
Rails::Engine defines a couple of further initializers for your application:
- set_load_path
- set_autoload_paths
- add_routing_paths
- add_routing_namespaces
- add_locales
- add_view_paths
- add_metals
- add_generator_templates
- load_application_initializers
- load_application_classes
These are explained in the Initialization section. TODO: First write initialization section then come back here and link.
Also in here we see that a couple of methods are +delegate+’d:
delegate :middleware, :paths, :root, :to => :configThis means when you call either the middleware, paths or root methods you are in reality calling config.middleware, config.paths and config.root respectively.
Rails::Engine descends from Rails::Railtie.
Rails::Railtie (pronounced Rail-tie, as in a bowtie), provides a method of classes to hook into Rails, providing them with methods to add generators, rake tasks and subscribers. All of the facets of Rails are their own Railtie. and as you’ve probably already figured out, the engines that you use are railties too. Plugins also can be railties, but they do not have to be.
Here there’s requires to rails/initializable.rb and and rails/configurable.rb.
The Rails::Initializable module includes methods helpful for the initialization process in rails, such as the method to define initializers: initializer. This is included into Rails::Railtie so it’s available there as well as Rails::Engine, Rails::Application and YourApp::Application. In here we also see the class definition for Rails::Initializer, the class for all initializer objects.
The Rails::Configuration module sets up shared configuration for applications, engines and plugins alike.
At the top of this file there are three +require+s:
require ‘active_support/ordered_options’ require ‘rails/paths’ require ‘rails/rack’ActiveSupport::OrderedOptions is a special-purpose OrderedHash, used for keeping track of the options specified in the configuration of your application.
TODO: expand.
This file is used to set up the Rails::Paths module which is used to set up helpers for referencing paths to the folders of your Rails application, such as in railties/lib/rails/engine/configuration.rb where it is used to firstly define them:
def paths @paths ||= begin paths = Rails::Paths::Root.new(@root) paths.app “app”, :eager_load => true, :glob => “*” paths.app.controllers “app/controllers”, :eager_load => true paths.app.helpers “app/helpers”, :eager_load => true paths.app.models “app/models”, :eager_load => true paths.app.mailers “app/mailers”, :eager_load => true paths.app.metals “app/metal”, :eager_load => true paths.app.views “app/views”, :eager_load => true paths.lib “lib”, :load_path => true paths.lib.tasks “lib/tasks”, :glob => “/.rake” paths.lib.templates “lib/templates” paths.config “config” paths.config.initializers “config/initializers”, :glob => “/.rb” paths.config.locales “config/locales”, :glob => “*.{rb,yml}” paths.config.routes “config/routes.rb” paths.public “public” paths.public.javascripts “public/javascripts” paths.public.stylesheets “public/stylesheets” paths end endYou can then get to these helper methods by calling YourApp::Application.config.paths.
This file sets up some +autoload+’d constants for Rails::Rack:
module Rails module Rack autoload :Debugger, “rails/rack/debugger” autoload :Logger, “rails/rack/logger” autoload :LogTailer, “rails/rack/log_tailer” autoload :Static, “rails/rack/static” end endNow we’re back to rails.rb. The line after require ‘rails/application’ in rails.rb is:
require ‘rails/version’The code in this file declares Rails::VERSION so that the version number can easily be accessed. It stores it in constants, with the final version number being attainable by calling Rails::VERSION::STRING.
This sets up a couple of familiar constants: RAILS_ENV, RAILS_ROOT and RAILS_DEFAULT_LOGGER to still be usable, but raise a deprecation warning when they are. Their alternatives are now Rails.env, Rails.root and Rails.logger respectively.
If you wish to know more about how they’re deprecated see the require ‘active_support/deprecation/proxy_wrappers’ section. TODO: link to section.
The Rails::LogSubscriber provides a central location for logging in Rails 3 so as to not slow down the main thread. When you call one of the logging methods (info, debug, warn, error, fatal or unknown) from the Rails::LogSubscriber class or one of its subclasses this will notify the Rails logger to log this call in the fashion you specify, but will not write it to the file. The file writing is done at the end of the request, courtesy of the Rails::Rack::Logger middleware.
Each Railtie defines its own class that descends from Rails::LogSubscriber with each defining its own methods for logging individual tasks.
This file ensures that you’re running a minimum of 1.8.7. If you’re running an older version, it will tell you:
Rails requires Ruby version 1.8.7 or later. You're running [your Ruby version here]; please upgrade to continue.
This file declares two Railties, one for ActiveSupport and the other for I18n. In these Railties there’s the following initializers defined:
- active_support.initialize_whiny_nils
- active_support.initialize_time_zone
- i18n.initialize
This Railtie also defines an an after_initialize block, which will (as the name implies) be ran after the initialization process. More on this later. TODO: When you write the section you can link to it.
This file is explained in the ActionDispatch Railtie Section. TODO: link
Now that we’ve covered the extensive process of what the first line does in this file, lets cover the remainder:
%w( active_record action_controller action_mailer active_resource rails/test_unit ).each do |framework| begin require “#{framework}/railtie” rescue LoadError end endAs you may be able to tell from the code, this is going through and loading all the Railties for Active Record, Action Controller, Action Mailer, Active Resource. Two other Railties, one for Active Support and one for Action Dispatch were required earlier, but are still covered in this section for continuity reasons. TODO: link.
From Active Support’s README:
Active Support is a collection of various utility classes and standard library extensions that were found useful for Rails.
TODO: Quotify.
The Active Record Railtie takes care of hooking Active Record into Rails. This depends on Active Support, Active Model and Arel. From Active Record’s readme:
TODO: Quotify.
Active Record connects business objects and database tables to create a persistable domain model where logic and data are presented in one wrapping. It’s an implementation of the object-relational mapping (ORM) pattern by the same name as described by Martin Fowler: “An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data." Active Record’s main contribution to the pattern is to relieve the original of two stunting problems: lack of associations and inheritance. By adding a simple domain language-like set of macros to describe the former and integrating the Single Table Inheritance pattern for the latter, Active Record narrows the gap of functionality between the data mapper and active record approach.The activerecord/lib/active_record/railtie.rb file defines the Railtie for Active Record.
This file first requires Active Record, the railties/lib/rails.rb file which has already been required and so will be ignored, and the Active Model Railtie:
require “active_record” require “rails” require “active_model/railtie”Active Model’s Railtie is covered in the next section. TODO: Section.
TODO: Why are activesupport_path and activemodel_path defined here?
The first three requires require ActiveSupport, Active Model and ARel in that order:
require ‘active_support’ require ‘active_model’ require ‘arel’This was loaded earlier by railties/lib/rails.rb. This line is here as a safeguard for when Active Record is loaded outside the scope of Rails.
TODO: Again with the activesupport_path!
Here we see another require “active_support” this is again, a safeguard for when Active Model is loaded outside the scope of Rails.
This file defines a few +autoload+’d modules for Active Model, requires active_support/i18n and adds the default translation file for Active Model to I18n.load_path.
The require ‘active_support/i18n’ just loads I18n and adds Active Support’s default translations file to I18n.load_path too:
require ‘i18n’ I18n.load_path << "#{File.dirname(FILE)}/locale/en.ymlThis file in arel/lib/arel.rb loads a couple of Active Support things first:
require ‘active_support/inflector’ require ‘active_support/core_ext/module/delegation’ require ‘active_support/core_ext/class/attribute_accessors’These files are explained in the “Common Includes” section.
Back in arel/lib/arel.rb, the next two lines require Active Record parts:
require ‘active_record’ require ‘active_record/connection_adapters/abstract/quoting’Because we’re currently loading active_record.rb, it skips right over it.
activerecord/lib/active_record/connection_adapters/abstract/quoting.rb defines methods used for quoting fields and table names in Active Record.
TODO: Explain why this is loaded especially.
Back the initial require from the railtie.rb.
The active_support and active_model requires are again just an insurance for if we’re loading Active Record outside of the scope of Rails. In active_record.rb the ActiveRecord Module is initialized and in it there is defined a couple of autoloads and eager_autoloads.
There’s a new method here called autoload_under which is defined in ActiveSupport::Autoload. This sets the autoload path to temporarily be the specified path, in this case relation for the +autoload+’d classes inside the block.
Inside this file the AttributeMethods, Locking and ConnectionAdapter modules are defined inside the ActiveRecord module. The second to last line tells Arel what SQL engine we want to use. In this case it’s ActiveRecord::Base. The final line adds in the translations for Active Record which are only for if a record is invalid or non-unique.
As mentioned previously this is skipped over as it has been already loaded. If you’d still like to see what this file does go to section TODO: section.
This is covered in the Active Model Railtie section. TODO: link there.
This is covered in the Action Controller Railtie section. TODO: link there.
Inside the Active Record Railtie the ActiveRecord::Railtie class is defined:
module ActiveRecord class Railtie < Rails::Railtie … end endTODO: Explain the logger.
By doing this the ActiveRecord::Railtie class gains access to the methods contained within Rails::Railtie such as rake_tasks, log_subscriber and initiailizer, all of which the Railtie is using in this case. The initializers defined here are:
- active_record.initialize_timezone
- active_record.logger
- active_record.set_configs
- active_record.initialize_database
- active_record.log_runtime
- active_record.initialize_database_middleware
- active_record.load_observers
- active_record.set_dispatch_hooks
As with the engine initializers, these are explained later.
This Railtie is +require+’d by Active Record’s Railtie.
From the Active Model readme:
Prior to Rails 3.0, if a plugin or gem developer wanted to be able to have an object interact with Action Pack helpers, it was required to either copy chunks of code from Rails, or monkey patch entire helpers to make them handle objects that did not look like Active Record. This generated code duplication and fragile applications that broke on upgrades. Active Model is a solution for this problem. Active Model provides a known set of interfaces that your objects can implement to then present a common interface to the Action Pack helpers.This Railtie file, activemodel/lib/active_model/railtie.rb is quite small and only requires in active_model. As mentioned previously, the require to rails is skipped over as it has been already loaded. If you’d still like to see what this file does go to section TODO: section.
require “active_model” require “rails”Active Model depends on Active Support and ensures it is required by making a require ‘active_support’ call. It has already been loaded from railties/lib/rails.rb so will not be reloaded for us here. The file goes on to define the ActiveModel module and all of its autoloaded classes. This file also defines the english translations for some of the validation messages provided by Active Model, such as “is not included in the list” and “is reserved”.
The Action Controller Railtie takes care of all the behind-the-scenes code for your controllers; it puts the C into MVC; and does so by implementing the ActionController::Base class which you may recall is where your ApplicationController class descends from.
This first makes a couple of requires:
require “action_controller” require “rails” require “action_view/railtie”The action_controller file is explained in the very next section. The require to rails is requiring the already-required railties/lib/rails.rb. If you wish to know about the require to action_view/railtie this is explained in the Action View Railtie section.
This file, actionpack/lib/action_controller.rb, defines the Action Controller module and its relative autoloads. Before it does any of that it makes two requires: one to abstract_controller, explored next, and the other to action_dispatch, explored directly after that.
AbstractController provides the functionality of TODO.
This file is in actionpack/lib/abstract_controller.rb and begins by attempting to add the path to Active Support to the load path, which it would succeed in if it wasn’t already set by anything loaded before it. In this case, it’s not going to be set due to Arel already loading it in (TODO: right?).
The next thing in this file four require calls:
require ‘active_support/ruby/shim’ require ‘active_support/dependencies/autoload’ require ‘active_support/core_ext/module/attr_internal’ require ‘active_support/core_ext/module/delegation’After these require calls the AbstractController module is defined with some standard +autoload+’d classes.
This file is explained in the “Common Includes” section beneath.
This file was loaded upon the first require of active_support and is not included. If you wish to be refreshed on what this file performs visit TODO: link to section.
This file is explained in the “Common Includes” section as it is required again later on. See the TODO: section. I also think this may be explained in the Active Support Core Extensions guide.
This file is explained in the “Common Includes” section as it has already been required by Arel at this point in the initialization process (see: section TODO: LINK!).
Back to actionpack/lib/action_controller.rb.
After the initial call to require ‘abstract_controller’, this calls require ‘action_dispatch’ which was required earlier by railties/lib/rails.rb. The purpose of this file is explained in the ActionDispatch Railtie section.
This file defines the ActionController module and its autoloaded classes.
Here we have a new method called autoload_under. This was covered in the Active Record Railtie but it is covered here also just in case you missed or skimmed over it. The autoload_under method is defined in ActiveSupport::Autoload and it sets the autoload path to temporarily be the specified path, in this case by specifying metal it will load the specified +autoload+’d classes from lib/action_controller/metal inside the block.
Another new method we have here is called autoload_at:
autoload_at “action_controller/metal/exceptions” do autoload :ActionControllerError autoload :RenderError autoload :RoutingError autoload :MethodNotAllowed autoload :NotImplemented autoload :UnknownController autoload :MissingFile autoload :RenderError autoload :SessionOverflowError autoload :UnknownHttpMethod endThis defines the path of which to find these classes defined at and is most useful for if you have multiple classes defined in a single file, as is the case for this block; all of those classes are defined inside action_controller/metal/exceptions.rb and when Active Support goes looking for them it will look in that file.
At the end of this file there are a couple more requires:
- All of these simply register additional autoloads
require ‘action_view’
require ‘action_controller/vendor/html-scanner’
- Common Active Support usage in ActionController
require ‘active_support/concern’
require ‘active_support/core_ext/class/attribute_accessors’
require ‘active_support/core_ext/load_error’
require ‘active_support/core_ext/module/attr_internal’
require ‘active_support/core_ext/module/delegation’
require ‘active_support/core_ext/name_error’
require ‘active_support/inflector’
This is best covered in the Action View Railtie section, so skip there by TODO: Link / page?
TODO: What is the purpose of this? Find out.
TODO: I can kind of understand the purpose of this.. need to see where @_dependencies is used however.
This file defines, as the path implies, attribute accessors for class. These are cattr_reader, cattr_writer, cattr_accessor.
The Active Support Core Extensions (TODO: LINK!) guide has a great coverage of what this file precisely provides.
This file is explained in the “Core Extension” guide.
This file was required through the earlier abstract_controller.rb require.
This file is explained in the “Common Includes” section.
This file was required earlier by Arel and so is not required again.
This file includes extensions to the NameError class, providing the missing_name and missing_name? methods. For more information see the Active Support Core Extensions guide.
This file is explained in the “Common Includes” section.
This file was earlier required by Arel and so is not required again.
So now we come back to the Action Controller Railtie with a couple more requires to go before ActionController::Railtie is defined:
require “action_view/railtie” require “active_support/core_ext/class/subclasses” require “active_support/deprecation/proxy_wrappers” require “active_support/deprecation”As explained previously the action_view/railtie file will be explained in the Action View Railtie section. TODO: link to it.
For an explanation of this file activesupport/lib/active_support/core_ext/class/subclasses, see the Active Support Core Extension guide.
This file, activesupport/lib/active_support/deprecation/proxy_wrappers.rb, defines a couple of deprecation classes, which are DeprecationProxy, DeprecationObjectProxy, DeprecationInstanceVariableProxy, DeprecationConstantProxy which are all namespaced into ActiveSupport::Deprecation. These last three are all subclasses of DeprecationProxy.
Why do we mention them here? Beside the obvious-by-now fact that we’re covering just about everything about the initialization process in this guide, if you’re deprecating something in your library and you use Active Support, you too can use the DeprecationProxy class (and it’s subclasses) too.
This class is used only in railties/lib/rails/deprecation.rb, loaded further on in the initialization process. It’s used in this way:
RAILS_ROOT = (Class.new(ActiveSupport::Deprecation::DeprecationProxy) do cattr_accessor :warned self.warned = false def target Rails.root end def replace(*args) warn(caller, :replace, *args) end def warn(callstack, called, args) unless warned ActiveSupport::Deprecation.warn(“RAILS_ROOT is deprecated! Use Rails.root instead”, callstack) self.warned = true end end end).newThere is similar definitions for the other constants of RAILS_ENV and RAILS_DEFAULT_LOGGER. All three of these constants are in the midst of being deprecated (most likely in Rails 3.1) so Rails will tell you if you reference them that they’re deprecated using the DeprecationProxy class. Whenever you call RAILS_ROOT this will raise a warning, telling you: “RAILS_ROOT is deprecated! Use Rails.root instead”…. TODO: investigate if simply calling it does raise this warning. This same rule applies to RAILS_ENV and RAILS_DEFAULT_LOGGER, their new alternatives are Rails.env and Rails.logger respectively.
This is used in one place actionpack/lib/action_controller/railtie.rb, which you may remember is how we got to the DeprecationProxy section:
ActiveSupport::Deprecation::DeprecatedObjectProxy.new(app.routes, message)This makes more sense in the wider scope of the initializer:
initializer “action_controller.url_helpers” do |app| ActionController.base_hook do extend ::ActionController::Railtie::UrlHelpers.with(app.routes) end message = "ActionController::Routing::Routes is deprecated. " \ “Instead, use Rails.application.routes” proxy = ActiveSupport::Deprecation::DeprecatedObjectProxy.new(app.routes, message) ActionController::Routing::Routes = proxy endActionController::Routing::Routes was the previous constant used in defining routes in Rails 2 applications, now it’s simply a method on Rails.application rather than it’s own individual class: Rails.application.routes. Both of these still call the draw method on the returned object to end up defining the routes.
This isn’t actually used anywhere in Rails anymore. It was used previously for when @request and @params were deprecated in Rails 2. It has been kept around as it could be useful for the same purposes in libraries that use Active Support.
This method is used in a couple of places, activesupport/lib/active_support/json/encoding.rb and railties/lib/rails/rack.rb.
In encoding.rb it’s used to define a constant that’s now been deprecated:
CircularReferenceError = Deprecation::DeprecatedConstantProxy.new(‘ActiveSupport::JSON::CircularReferenceError’, Encoding::CircularReferenceError)Now when you reference ActiveSupport::JSON::CircularReferenceError you’ll receive a warning:
ActiveSupport::JSON::CircularReferenceError is deprecated! Use Encoding::CircularReferenceError instead.This re-opens the ActiveSupport::Deprecation module which was already defined by our deprecation proxies. Before this happens however we have 4 requires:
require ‘active_support/deprecation/behaviors’ require ‘active_support/deprecation/reporting’ require ‘active_support/deprecation/method_wrappers’ require ‘active_support/deprecation/proxy_wrappers’The remainder of this file goes about setting up the silenced and debug accessors:
module ActiveSupport module Deprecation #:nodoc: class << self- The version the deprecated behavior will be removed, by default.
attr_accessor :deprecation_horizon
end
self.deprecation_horizon = ‘3.0’
- By default, warnings are not silenced and debugging is off.
self.silenced = false
self.debug = false
end
end
This sets up some default behavior for the warnings raised by ActiveSupport::Deprecation, defining different ones for development and test and nothing for production, as we never want deprecation warnings in production:
- Default warning behaviors per Rails.env. Ignored in production.
DEFAULT_BEHAVIORS = {
‘test’ => Proc.new { |message, callstack|
$stderr.puts(message)
$stderr.puts callstack.join("\n “) if debug
},
‘development’ => Proc.new { |message, callstack|
logger =
if defined?(Rails) && Rails.logger
Rails.logger
else
require ‘logger’
Logger.new($stderr)
end
logger.warn message
logger.debug callstack.join(”\n ") if debug
}
}
In the test environment, we will see the deprecation errors displayed in $stderr and in development mode, these are sent to Rails.logger if it exists, otherwise it is output to $stderr in a very similar fashion to the test environment. These are both defined as procs, so Active Support can pass arguments to the call method we call on it when Active Support warn.
This file defines further extensions to the ActiveSupport::Deprecation module, including the warn method which is used from Active Support’s DeprecationProxy class and an attr_accessor on the class called silenced. This checks that we have a behavior defined, which we do in the test and development environments, and that we’re not silenced before warning about deprecations by +call+’ing the Proc time.
This file also defines a silence method on the module also which you can pass a block to temporarily silence errors:
ActiveSupport::Deprecation.silence do puts “YOU CAN FIND ME HERE: #{RAILS_ROOT}” endTODO: may have to correct this example.
This file defines a class method on ActiveSupport::Deprecation called deprecate_methods. This method is used in activesupport/lib/active_support/core_ext/module/deprecation.rb to allow you to declare deprecated methods on modules:
class Module- Declare that a method has been deprecated.
- deprecate :foo
- deprecate :bar => ‘message’
- deprecate :foo, :bar, :baz => ‘warning!’, :qux => ‘gone!’
def deprecate(*method_names)
ActiveSupport::Deprecation.deprecate_methods(self, *method_names)
end
end
Inside ActionController::Railtie there are another two requires:
require “action_controller/railties/log_subscriber” require “action_controller/railties/url_helpers”ActionController::Railties::LogSubscriber inherits from Rails::LogSubscriber and defines methods for logging such things as action processing and file sending.
This file defines a with method on ActionController::Railtie::UrlHelpers which is later used in the action_controller.url_helpers initializer. For more information see the action_controller.url_helpers initializer section.
After these requires it deprecates a couple of ex-Action Controller methods and points whomever references them to their ActionDispatch equivalents. These methods are session, session=, session_store and session_store=.
After the deprecations, Rails defines the log_subscriber to be a new instance of ActionController::Railties::LogSubscriber and then go about defining the following initializers, keeping in mind that these are added to the list of initializers defined before hand:
- action_controller.logger
- action_controller.set_configs
- action_controller.initialize_framework_caches
- action_controller.set_helpers_path
- action_controller.url_helpers
The Action View Railtie provides the backend code for your views and it puts the C into MVC. This implements the ActionView::Base of which all views and partials are objects of.
The Railtie is defined in a file called actionpack/lib/action_view/railtie.rb and initially makes a call to require ‘action_view’.
Here again we have the addition of the path to Active Support to the load path attempted, but because it’s already in the load path it will not be added. Similarly, we have two requires:
require ‘active_support/ruby/shim’ require ‘active_support/core_ext/class/attribute_accessors’And these have already been required. If you wish to know what these files do go to the explanation of each in the “Common Includes” section. TODO: link to them!
This file goes on to require ‘action_pack’ which consists of all this code (comments stripped):
require ‘action_pack/version’the version file contains this code (comments stripped):
module ActionPack #:nodoc: module VERSION #:nodoc: MAJOR = 3 MINOR = 0 TINY = “0.beta1” STRING = [MAJOR, MINOR, TINY].join(‘.’) end endTODO: Why?!
This file goes on to define the ActionView module and its +autoload+’d modules and then goes on to make two more requires:
require ‘active_support/core_ext/string/output_safety’ require ‘action_view/base’The actionpack/lib/active_support/core_ext/string/output_saftey.rb file is responsible for the code used in escaping HTML and JSON, namely the html_escape and json_escape methods. It does this by overriding these methods in Erb::Util which is later included into ActionView::Base. This also defines ActiveSupport::SafeBuffer which descends from String and is used for concatenating safe output from your views to ERB templates.
This file initially makes requires to the following files:
require ‘active_support/core_ext/module/attr_internal’ require ‘active_support/core_ext/module/delegation’ require ‘active_support/core_ext/class/attribute’These are explained in their relevant areas inside the “Common Includes” section.
The remainder of this file sets up the ActionView module and the ActionView::Base class which is the class of all view templates. Inside of ActionView::Base it makes an include to several helper modules:
include Helpers, Rendering, Partials, Layouts, ::ERB::Util, ContextThis module, from actionpack/lib/action_view/helpers.rb_, initially sets up the +autoload+’s for the various ActionView::Helpers modules (TODO: mysteriously not using +autoloadunder+). This also sets up a ClassMethods module which is included automatically into wherever ActionView::Helpers is included by defining a self.included method:
def self.included(base) base.extend(ClassMethods) end module ClassMethods include SanitizeHelper::ClassMethods endInside of SanitizeHelper::ClassMethods it defines, of course, methods for assisting with sanitizing in Rails such as link_sanitizer which is used by the strip_links method.
Afterwards this includes the ActiveSupport::Benchmarkable which is used for benchmarking how long a specific thing takes in a view. The method is simply benchmark and can be used like this:
benchmark(“potentially long running thing”) do Post.count endThe documentation is great about explaining what precisely this does. (TODO: replace link with real documentation link when it becomes available.)
This module is also included into Active Record and AbstractController, meaning you can also use the benchmark method in these methods.
After including ActiveSupport::Benchmarkable, the helpers which we have declared to be +autoload+’d are included. I will not go through and cover what each of these helpers do, as their names should be fairly explicit about it, and it’s not really within the scope of this guide.
This module, from actionpack/lib/action_view/render/rendering.rb defines a method you may be a little too familiar with: render. This is the render use for rendering all kinds of things, such as partials, templates and text.
This module, from actionpack/lib/action_view/render/partials.rb, defines ActionView::Partials::PartialRenderer which you can probably guess is used for rendering partials.
This module, from actionpack/lib/action_view/render/layouts.rb_, defines ActionView::Layouts which defines methods such as +findlayout+ for locating layouts.
The ERB::Util module from Ruby core, as the document describes it: “A utility module for conversion routines, often handy in HTML generation”. It offers two methods html_escape and url_encode, with a third called json_escape being added in by the requirement of actionpack/lib/active_support/core_ext/string/output_saftey.rb earlier. As explained earlier, html_escape is overridden to return a string marked as safe.
TODO: Not entirely sure what this is all about. Something about the context of view rendering… can’t work it out.
Now that actionpack/lib/action_view.rb has been required, the next step is to require ‘rails’, but this will be skipped as the file was required by railties/lib/rails/all.rb way back in the beginnings of the initialization process.
Next, the Railtie itself is defined:
module ActionView class Railtie < Rails::Railtie railtie_name :action_view require “action_view/railties/log_subscriber” log_subscriber ActionView::Railties::LogSubscriber.new initializer “action_view.cache_asset_timestamps” do |app| unless app.config.cache_classes ActionView.base_hook do ActionView::Helpers::AssetTagHelper.cache_asset_timestamps = false end end end end endThe ActionView::LogSubscriber sets up a method called render_template which is called when a template is rendered. TODO: Templates only or partials and layouts also? I would imagine these fall under the templates category, but there needs to research to ensure this is correct.
The sole initializer defined here, action_view.cache_asset_timestamps is responsible for caching the timestamps on the ends of your assets. If you’ve ever seen a link generated by image_tag or stylesheet_link_tag you would know that I mean that this timestamp is the number after the ? in this example: /javascripts/prototype.js?1265442620_. This initializer will do nothing if +cacheclasses+ is set to false in any of your application’s configuration. TODO: Elaborate.
The Action Mailer Railtie is responsible for including all the emailing functionality into Rails by way of the Action Mailer gem itself. Action Mailer is:
Action Mailer is a framework for designing email-service layers. These layers
are used to consolidate code for sending out forgotten passwords, welcome
wishes on signup, invoices for billing, and any other use case that requires
a written notification to either a person or another system.
Action Mailer is in essence a wrapper around Action Controller and the
Mail gem. It provides a way to make emails using templates in the same
way that Action Controller renders views using templates.
TODO: Quotify.
This file first makes two requires:
require “action_mailer” require “rails”The requires in action_mailer are already loaded or are core extensions:
require ‘abstract_controller’ require ‘action_view’- Common Active Support usage in Action Mailer
require ‘active_support/core_ext/class’
require ‘active_support/core_ext/object/blank’
require ‘active_support/core_ext/array/uniq_by’
require ‘active_support/core_ext/module/attr_internal’
require ‘active_support/core_ext/module/delegation’
require ‘active_support/core_ext/string/inflections’
require ‘active_support/lazy_load_hooks’
abstract_controller is covered in the “Action Controller Railtie” section. TODO: Cover AbstractController there and link to it.
action_view was required by the Action View Railtie and will not be required again.
For the core extensions you may reference the “Core Extensions” guide. TODO: Link to guide.
active_support/lazy_load_hooks was covered earlier in the guide and since it has already been required at this point in the initialization process, it will not be required again.
The require “rails” is referencing the railties/lib/rails.rb file which was included back in TODO: link to section.
actionmailer/lib/action_mailer.rb then goes on to define the ActionMailer module:
module ActionMailer extend ::ActiveSupport::Autoload autoload :AdvAttrAccessor autoload :Collector autoload :Base autoload :DeliveryMethods autoload :DeprecatedApi autoload :MailHelper autoload :OldApi autoload :Quoting autoload :TestCase autoload :TestHelper endAnd a Text module too:
module Text extend ActiveSupport::Autoload autoload :Format, ‘text/format’ endwhich is used by the ActionMailer::MailerHelper method block_format:
def block_format(text) formatted = text.split(/\n\r\n/).collect { |paragraph| Text::Format.new( :columns => 72, :first_indent => 2, :body_indent => 2, :text => paragraph ).format }.join(“\n”)- Make list points stand on their own line
formatted.gsub!(/[ ]([) ([^])/) { |s| " #{$1} #{$2.strip}\n" }
formatted.gsub!(/[ ]*([#]) ([^#]*)/) { |s| " #{$1} #{$2.strip}\n" }
The Railtie defines the log_subscriber as ActionMailer::Railties::LogSubscriber.new, with this class having two logging methods: one for delivery called deliver and one for receipt called receive.
The initializers defined in this Railtie are:
- action_mailer.url_for
- action_mailer.logger
- action_mailer.set_configs
These are covered later on the Initialization section. TODO: first write then link to Initialization section.
The Active Resource Railtie is responsible for creating an interface into remote sites that offer a REST API. The Active Resource Railtie depends on Active Support and Active Model.
This file defines the Active Resource Railtie:
require “active_resource” require “rails” module ActiveResource class Railtie < Rails::Railtie railtie_name :active_resource require “active_resource/railties/log_subscriber” log_subscriber ActiveResource::Railties::LogSubscriber.new initializer “active_resource.set_configs” do |app| app.config.active_resource.each do |k,v| ActiveResource::Base.send “#{k}=”, v end end end endThe require ‘rails’ has already been done back in TODO: link to section.
This file, activeresource/lib/active_resource.rb_, defines the ActiveResource module, first off this will add the path to Active Support and Active Model to the load path if it’s not already there, then require both active_support (activesupport/lib/active_support.rb_) and active_model (_activemodel/lib/activemodel.rb)
activesupport_path = File.expand_path(‘../../../activesupport/lib’, FILE) $:.unshift(activesupport_path) if File.directory?(activesupport_path) && !$:.include?(activesupport_path) activemodel_path = File.expand_path(‘../../../activemodel/lib’, FILE) $:.unshift(activemodel_path) if File.directory?(activemodel_path) && !$:.include?(activemodel_path) require ‘active_support’ require ‘active_model’ module ActiveResource extend ActiveSupport::Autoload autoload :Base autoload :Connection autoload :CustomMethods autoload :Formats autoload :HttpMock autoload :Observing autoload :Schema autoload :Validations endThe Railtie itself is fairly short as Active Resource is the smallest component of Rails.
module ActiveResource class Railtie < Rails::Railtie railtie_name :active_resource require “active_resource/railties/log_subscriber” log_subscriber ActiveResource::Railties::LogSubscriber.new initializer “active_resource.set_configs” do |app| app.config.active_resource.each do |k,v| ActiveResource::Base.send “#{k}=”, v end end end endThe Railtie defines the log_subscriber as ActiveResource::Railties::LogSubscriber.new which has one method defined: request. request is used whenever a request is made to an external service.
There is only one initializer defined here: set_configs. This is covered later in the Initialization section.
ActionDispatch handles all dispatch work for Rails. It interfaces with Action Controller to determine what action to undertake when a request comes in. TODO: I would quote the README but it is strangely absent. Flyin’ blind here!
The ActionDispatch Railtie was previously required when we called require ‘rails’, but we will cover the Railtie here too.
ActionDispatch depends on Active Support.
This file defines the ActionDispatch Railtie:
require “action_dispatch” require “rails” module ActionDispatch class Railtie < Rails::Railtie railtie_name :action_dispatch config.action_dispatch.x_sendfile_header = “X-Sendfile” config.action_dispatch.ip_spoofing_check = true- Prepare dispatcher callbacks and run ‘prepare’ callbacks
initializer “action_dispatch.prepare_dispatcher” do |app| - TODO: This used to say unless defined?(Dispatcher). Find out why and fix.
require ‘rails/dispatcher’
ActionDispatch::Callbacks.to_prepare { app.routes_reloader.reload_if_changed }
end
end
end
The require ‘rails’ has already been done back in TODO: link to section.
This file was already loaded earlier in the initialization process. TODO: link to it.
The ActionDispatch Railtie is almost as short as the Active Resource Railtie:
require “action_dispatch” require “rails” module ActionDispatch class Railtie < Rails::Railtie railtie_name :action_dispatch config.action_dispatch.x_sendfile_header = “X-Sendfile” config.action_dispatch.ip_spoofing_check = true- Prepare dispatcher callbacks and run ‘prepare’ callbacks
initializer “action_dispatch.prepare_dispatcher” do |app| - TODO: This used to say unless defined?(Dispatcher). Find out why and fix.
require ‘rails/dispatcher’
ActionDispatch::Callbacks.to_prepare { app.routes_reloader.reload_if_changed }
end
end
end
The config method here is from Rails::Railtie and pertains to your application’s configuration. In this case, it is setting up some defaults which you can later override in config/application.rb.
This Railtie does not define a log_subscriber and only defines one initializer: prepare_dispatcher.
Now that Rails has finished loading all the Railties by way of require ‘rails/all’ Rails can now move on to the next line:
Bundler.require :default, Rails.envNOTE: It is worth mentioning here that you are not tied to using Bundler with Rails 3, but it is (of course) advised that you do. To “turn off” Bundler, comment out or remove the corresponding lines in config/application.rb and config/boot.rb.
Bundler was +require+’d back in config/boot.rb, and so that is what makes it available here. This guide does not dive into the internals of Bundler; it’s really it’s own separate guide.
The Bundler.require method adds all the gems not specified inside a group in the Gemfile and the ones specified in groups for the Rails.env (in this case, development), to the load path. This is how an application is able to find them.
The rest of this file is spent defining your application’s main class. This is it without the comments:
module YourApp class Application < Rails::Application config.encoding = “utf-8” config.filter_parameters += [:password] end endOn the surface, this looks like a simple class inheritance. There’s more underneath though. back in Rails::Application, the inherited method is defined:
def inherited(base) raise “You cannot have more than one Rails::Application” if Rails.application super Rails.application = base.instance endWe do not already have a Rails.application, so instead this resorts to calling super. Rails::Application descends from Rails::Engine and so will call the inherited method in Rails::Engine, but before that it’s important to note that called_from is defined an attr_accessor on Rails::Engine:
def inherited(base) unless base.abstract_railtie? base.called_from = begin- Remove the line number from backtraces making sure we don’t leave anything behind
call_stack = caller.map { |p| p.split(‘:’)[0..-2].join(‘:’) }
File.dirname(call_stack.detect { |p| p !~ %r[railties[\w\-\.]/lib/rails|rack[\w\-\.]/lib/rack] })
end
end
This called_from setting looks a little overwhelming to begin with, but the short end of it is that it returns the route to your application’s config directory, something like: /home/you/yourapp/config_. After +calledfrom+ has been set, super is again called and this means the Rails::Railtie#inherited method.
Now that we’ve covered the boot process of Rails the next line best to cover would be what happens after script/rails has loaded config/boot.rb. That’s quite simply that it then require ‘rails/commands’ which is located at railties/lib/rails/commands.rb. Remember how exec passed the arguments to script/rails? This is where they’re used. rails/commands.rb is quite a large file in Rails 3, as it contains all the Rails commands like console, about, generate and, of course, server. Because we’ve called rails server the first argument in ARGV is of course “server”. So assuming this we can determine that the ARGV.shift in commands.rb is going to return “server”, therefore it’ll match this when:
when ‘s’, ‘server’ require ‘rails/commands/server’ Dir.chdir(ROOT_PATH) Rails::Server.startThe keen-eyed observer will note that this when also specifies the argument could also be simply ‘s’ thereby making the full command rails s. This is the same with the other commands with generate becoming g, console becoming c and dbconsole becoming db.
This code here ensures we are at the ROOT_PATH of our application (this constant was defined in script/rails) and then calls Rails::Server.start. Rails::Server descends from Rack::Server which is defined in the rack gem. The Rails::Server.start method is defined like this:
def start ENV[“RAILS_ENV”] = options[:environment] puts “=> Booting #{ActiveSupport::Inflector.demodulize(server)}” puts “=> Rails #{Rails.version} application starting in #{Rails.env} on http://#{options[:Host]}:#{options[:Port]}” puts “=> Call with -d to detach” unless options[:daemonize] trap(:INT) { exit } puts “=> Ctrl-C to shutdown server” unless options[:daemonize] super ensure puts ‘Exiting’ unless options[:daemonize] endWe can see here that there is usual output indicating that the server is booting up.
How the options variable gets set and how Rack starts the server up is covered in the next section.
This Rack::Server.start method is defined like this:
def self.start new.start endnew as you know calls initialize in a class, and that is defined like this:
def initialize(options = nil) @options = options endAnd then options, which are the options referenced by the start method in Rails::Server.
def options @options ||= parse_options(ARGV) endAnd parse_options:
def parse_options(args) options = default_options- Don’t evaluate CGI ISINDEX parameters.
- http://hoohoo.ncsa.uiuc.edu/cgi/cl.html
args.clear if ENV.include?(“REQUEST_METHOD”)
And default_options:
def default_options { :environment => “development”, :pid => nil, :Port => 9292, :Host => “0.0.0.0”, :AccessLog => [], :config => “config.ru” } endFinally! We’ve arrived at default_options which leads into our next point quite nicely. After the object has been +initialize+’d, start is called:
def start if options[:debug] $DEBUG = true require ‘pp’ p options[:server] pp wrapped_app pp app end if options[:warn] $-w = true end if includes = options[:include] $LOAD_PATH.unshift *includes end if library = options[:require] require library end daemonize_app if options[:daemonize] write_pid if options[:pid] server.run wrapped_app, options endWe’re not debugging anything, so there goes the first 7 lines, we’re not warning, nor are we including, requiring, daemonising or writing out a pid file. That’s everything except the final line, which calls run with the wrapped_app which is then defined like this:
def wrapped_app @wrapped_app ||= build_app app endand +build_app+’s first and only argument is app which is defined like this:
def app @app ||= begin if !::File.exist? options[:config] abort “configuration #{options[:config]} not found” end app, options = Rack::Builder.parse_file(self.options[:config], opt_parser) self.options.merge! options app end endoptions is a method we talked about a short while ago, which is just the set of default options. options[:config] in this context is therefore config.ru which coincidentally we have in our application! To get an application instance from this method Rack::Builder joins the fray with a call to parse_file on our config.ru:
def self.parse_file(config, opts = Server::Options.new) options = {} if config =~ /\.ru$/ cfgfile = ::File.read(config) if cfgfile[/^#\\(.*)/] && opts options = opts.parse! $1.split(/\s+/) end cfgfile.sub!(/^END\n.*/, ’’) app = eval "Rack::Builder.new {( " + cfgfile + “\n )}.to_app”, TOPLEVEL_BINDING, config else require config app = Object.const_get(::File.basename(config, ‘.rb’).capitalize) end return app, options endFirst this reads your config file and checks it for #\ at the beginning. This is supported if you want to pass options into the Rack::Server instance that you have and can be used like this:
#\\ -E production- This file is used by Rack-based servers to start the application.
TODO: Is the above correct? I am simply guessing!
After that it removes all the content after any END in your config.ru (TODO: because? Is this so it doesn’t get eval’d?) and then evals the content of this file which, as you’ve seen is quite simple. The code that’s first evaluated would be the require to the config/environment.rb file, which leads into the next section.
Now that we’ve seen that rails/server gets to config/environment.rb via Rack’s requiring of it and Passenger requires it straight off the line. We’ve covered the boot process of Rails and covered the beginnings of a Rack server starting up. We have reached a common path for both rails/server and Passenger now, so let’s investigate what config/environment.rb does.
- Load the rails application
require File.expand_path(‘../application’, FILE)
- Initialize the rails application
YourApp::Application.initialize!
As you can see, there’s a require in here for config/application.rb, and this file looks like this:
module YourApp class Application < Rails::Application- Settings in config/environments/* take precedence over those specified here.
- Application configuration should go into files in config/initializers
- — all .rb files in that directory are automatically loaded.
- Add additional load paths for your own custom dirs
- config.load_paths += %W( #{config.root}/extras )
- Only load the plugins named here, in the order given (default is alphabetical).
- :all can be used as a placeholder for all plugins not explicitly named
- config.plugins = [ :exception_notification, :ssl_requirement, :all ]
- Activate observers that should always be running
- config.active_record.observers = :cacher, :garbage_collector, :forum_observer
- Set Time.zone default to the specified zone and make Active Record auto-convert to this zone.
- Run “rake -D time” for a list of tasks for finding time zone names. Default is UTC.
- config.time_zone = ‘Central Time (US & Canada)’
- The default locale is :en and all translations from config/locales/*.rb,yml are auto loaded.
- config.i18n.load_path += Dir[Rails.root.join(‘my’, ‘locales’, ‘*.{rb,yml}’)]
- config.i18n.default_locale = :de
- Configure generators values. Many other options are available, be sure to check the documentation.
- config.generators do |g|
- g.orm :active_record
- g.template_engine :erb
- g.test_framework :test_unit, :fixture => true
- end
end
end
These options (and their siblings) are explained in a later section. What’s important to note for this file currently is that this is where the YourApp::Application class is initialized and that it’s a subclass of Rails::Application. This is the first point where your application begins to initialize Rails and as you can see all of this is configuration stuff which your initializers and really, the rest of your application will depend on. These options and what they do will be covered later.
Now begins the actual initialization of Rails. Previously we have covered how rails server and Passenger get to this stage and the parts of Rails that they have both loaded.
The first steps for the initialization process of Rails begins when YourApp::Application descends from Rails::Application. The Rails::Application class descends from Rails::Engine class which itself descends from Rails::Railtie defined in railties/lib/rails/railtie.rb. Along this fantastical chain of superclasses, there’s defined a couple of inherited class methods. These methods just so happen to be called when a class inherits from (aka: is made a subclass of) this class. This first one is for Rails::Application:
def inherited(base) raise “You cannot have more than one Rails::Application” if Rails.application super Rails.application = base.instance endThis goes up the chain by using super to calling Rails::Engine.inherited:
def inherited(base) unless abstract_railtie?(base) base.called_from = begin call_stack = caller.map { |p| p.split(‘:’).first } File.dirname(call_stack.detect { |p| p !~ %r[railties/lib/rails|rack/lib/rack] }) end end super endcalled_from references where this code was called from. This is covered later on in the “Bootstrap Initializers” section.
Which then calls Rails::Railtie.inherited:
def inherited(base) unless abstract_railtie?(base) base.send(:include, self::Configurable) subclasses << base end endThis inherited first includes the Rails::Configurable module on base, which is YourApp::Application. This module defines the config method on YourApp::Application, and now it’s starting to come together. You may notice that in your config/application.rb file there’s a config method called there. This is the method from Rails::Configurable.
Then this adds to Rails::Railtie.subclasses your application’s class because… TODO: explain.
With Rails::Railtie.inherited out of the way, and that being the last thing to do in Rails::Engine.inherited we return to Rails::Application.inherited which calls the following:
Rails.application = base.instanceAs you already know, base is YourApp::Application and now it’s calling the instance method on it. This method is defined in Rails::Application like this:
def instance if self == Rails::Application Rails.application else @@instance ||= new end endThe new method here simply creates a new Rails::Application and sets it to the @@instance class variable. No magic.
Now that inherited has finished doing its job, next up in config/application.rb is the call to the config object’s methods. As explained before, this config object is an instance of Rails::Railtie::Configuration, put into place by the call of include Rails::Configurable back in Rails::Railtie.inherited. This defined it as such:
def config @config ||= Railtie::Configuration.new endAll the methods for Rails::Railtie::Configuration are defined like this in railties/lib/rails/railtie/configuration.rb:
require ‘rails/configuration’ module Rails class Railtie class Configuration include Rails::Configuration::Shared end end endAs you can probably guess here, the Rails::Configuration module is defined by rails/configuration (railties/lib/rails/configuration.rb).
In a standard application, the application.rb looks like this with all the comments stripped out:
require File.expand_path(‘../boot’, FILE) module YourApp class Application < Rails::Application config.filter_parameters << :password end endThe config method being the one defined on Rails::Application::Configurable:
def config @config ||= Application::Configuration.new(self.class.find_root_with_flag(“config.ru”, Dir.pwd)) endThe method find_with_root_flag is defined on Rails::Engine (the superclass of Rails::Application) and it will find the directory containing a certain flag. In this case it’s the config.ru file:
def find_root_with_flag(flag, default=nil) root_path = self.called_from while root_path && File.directory?(root_path) && !File.exist?(“#{root_path}/#{flag}”) parent = File.dirname(root_path) root_path = parent != root_path && parent end root = File.exist?(“#{root_path}/#{flag}”) ? root_path : default raise “Could not find root path for #{self}” unless root RUBY_PLATFORM =~ /(:?mswin|mingw)/ ? Pathname.new(root).expand_path : Pathname.new(root).realpath endcalled_from goes through the caller which is the stacktrace of the current thread, in the case of your application it would go a little like this:
/usr/local/lib/ruby/gems/1.9.1/gems/railties-3.0.0.beta1/lib/rails/application.rb:30:in `inherited' /home/you/yourapp/config/application.rb:4:in `<module:TestApp>' /home/you/yourapp/config/application.rb:3:in `<top (required)>' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:167:in `require' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:167:in `block in require' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:537:in `new_constants_in' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:167:in `require' /usr/local/lib/ruby/gems/1.9.1/gems/railties-3.0.0.beta1/lib/rails/commands.rb:33:in `<top (required)>' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:167:in `require' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:167:in `block in require' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:537:in `new_constants_in' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:167:in `require' /var/www/rboard/script/rails:10:in `<main>'
called_from is defined in the inherited method for Rails::Engine which looks like this:
base.called_from = begin call_stack = caller.map { |p| p.split(‘:’).first } File.dirname(call_stack.detect { |p| p !~ %r[railties/lib/rails|rack/lib/rack] }) endThe call_stack here is the caller output shown previously, minus everything after the first : on all the lines. The first path that matches this is /usr/local/lib/ruby/gems/1.9.1/gems/railties-3.0.0.beta1/lib/rails. Yours may vary slightly, but should always end in railties-x.×.x/lib/rails.
The code in find_root_with_flag will go up this directory structure until it reaches the top, which in this case is /.
while root_path && File.directory?(root_path) && !File.exist?(“#{root_path}/#{flag}”) parent = File.dirname(root_path) root_path = parent != root_path && parent end root = File.exist?(“#{root_path}/#{flag}”) ? root_path : default raise “Could not find root path for #{self}” unless rootTODO: What is all this for?
At the root of the system it looks for config.ru. TODO: Why? Obviously it’s not going to find it, so it uses the default option we’ve specified which is Dir.pwd which will default to the root folder of your Rails application. This path is then passed to Rails::Application::Configuration.new. Rails::Application::Configuration descends from Rails::Engine::Configuration and the initialize method goes like this:
def initialize(*) super @allow_concurrency = false @colorize_logging = true @filter_parameters = [] @dependency_loading = true @serve_static_assets = true @time_zone = “UTC” @consider_all_requests_local = true endThe super method here is the initialize method in Rails::Engine::Configuration:
def initialize(root=nil) @root = root endHere, the @root variable is assigned the path of your application and then the remainder of Rails::Application::Configuration.initialize is ran, setting up a few instance variables for basic configuration, including one for @filter_parameters.
Now with the config option set up, we can go onwards and call filter_parameters on it. This filter_parameters method is not defined on Rails::Configuration::Shared and actually falls to the method_missing defined there instead:
def method_missing(name, *args, &blk) if name.to_s =~ config_key_regexp return $2 == ‘=’ ? options[$1] = args.first : options[$1] end super endWe’re not calling filter_parameters=, we’re calling filter_parameters, therefore it’ll be the second part of this ternary argument: options[$1]. The options method is defined like this:
def options @@options ||= Hash.new { |h,k| h[k] = ActiveSupport::OrderedOptions.new } endOrderedOptions exists… TODO: explain.
So from this we can determine that our options hash now has a key for filter_parameters which’s value is an array consisting of a single symbol: :password. How this option manages to get into the @filter_parameters variable defined on the Rails::Application::Configuration.initialize method is explained later.
Now your application has finished being configured (at least in the sense of config/application.rb, there’s more to come!) in config/environment.rb the final line calls YourApp::Application.initalize!.
This is one of those magical uses of method_missing which, for the purposes of debugging, is something that you don’t expect to come across as often as you do and as a consequence you’ll spend a good portion of an hour looking for method definitions that don’t exist because method_missing is taking care of it. There’s some pretty crafty use of method_missing all over Rails and it’s encouraged to take note of its power.
Rails::Application has a method_missing definition which does this:
def method_missing(*args, &block) instance.send(*args, &block) endWith our instance being our already initialized by the inherited method, this will just return the value of the @@instance variable, a Rails::Application object. Calling initialize! on this method does this:
def initialize! run_initializers(self) self endThe initializers it is talking about running here are the initializers for our application. The object passed in to run_initializers is YourApp::Application.
This method begins the running of all the defined initializers. In the section “The Boot Process” we covered the loading sequence of Rails before any initialization happens and during this time we saw that the Rails::Railtie class includes the Initializable module. As we’ve also seen YourApp::Application is a descendant of this class, so it too has these methods.
run_initializers looks like this:
def run_initializers(*args) return if instance_variable_defined?(:@ran) initializers.each do |initializer| initializer.run(*args) end @ran = true endHere the initializers method is defined in railties/lib/rails/application.rb:
def initializers initializers = Bootstrap.initializers_for(self) railties.all { |r| initializers += r.initializers } initializers += super initializers += Finisher.initializers_for(self) initializers endThe first line here references a Bootstrap class we haven’t seen before. Or have we? The keen-eyed observer would have spotted an autoload for it at the top of Rails::Application:
autoload :Bootstrap, ‘rails/application/bootstrap’Now that we’ve referenced that class, it will be required for us. You’ll notice inside this class that there’s an include Initializable, providing the afore-mentioned methods from this module. Inside this class a number of initializers are defined.
- load_environment_config
- load_all_active_support
- preload_frameworks
- initialize_logger
- initialize_cache
- initialize_subscriber
- set_clear_dependencies_hook
- initialize_dependency_mechanism
These are all defined using the initializer method:
def initializer(name, opts = {}, &blk) raise ArgumentError, “A block must be passed when defining an initializer” unless blk opts[:after] ||= initializers.last.name unless initializers.empty? || initializers.find { |i| i.name == opts[:before] } initializers << Initializer.new(name, nil, opts, &blk) endThe initializers method defined here just references an @initializers variable:
def initializers @initializers ||= [] endAs you can see from this method it will set opts[:after] if there are previously defined initializers. So we can determine from this that the order our initializers are defined in is the same order that they run in, but only by default. It is possible to change this by specifying an :after or :before option as we will see later on. Each initializer is its own instance of the Initializer class:
class Initializer attr_reader :name, :block def initialize(name, context, options, &block) @name, @context, @options, @block = name, context, options, block end def before @options[:before] end def after @options[:after] end def run(*args) @context.instance_exec(*args, &block) end def bind(context) return self if @context Initializer.new(@name, context, @options, &block) end endNow that Rails::Application::Bootstrap has finished loading, we can continue on with our initialization. We saw that it called this:
initializers = Bootstrap.initializers_for(self)Calling initializers_for, defined like this:
def initializers_for(binding) Collection.new(initializers_chain.map { |i| i.bind(binding) }) endThe binding argument here is YourApp::Application and this will return a new Initializer object for all the initializers in initializers_chain for this particular context. initializers_chain goes like this:
def initializers_chain initializers = Collection.new ancestors.reverse_each do |klass| next unless klass.respond_to?(:initializers) initializers = initializers + klass.initializers end initializers endThe ancestors list is relatively short for Rails::Application::Bootstrap, consisting of itself and Rails::Initializable. Rails will go through these ancestors in reverse and check them all if they respond_to?(:initializers). Rails::Initializable does not and so it’s skipped. Rails::Application::Bootstrap of course does, and this is the list of initializers we covered earlier.
After initializers_chain is finished, then they are +map+’d like this, with the binding of course being YourApp::Application as explained previously.
def initializers_for(binding) Collection.new(initializers_chain.map { |i| i.bind(binding) }) endWow. All that to cover just the first line in the initializers method for Rails::Application.
This section covers the loading of the initializers and we will go into depth for each initializer in the next section, as they make more sense explained in their chain.
The second line in Rails::Application#initializers:
def initializers railties.all { |r| initializers += r.initializers } endcalls railties, which is defined like this:
def railties @railties ||= Railties.new(config) endThis sets up a new Rails::Application::Railties object like this:
def initialize(config) @config = config endAnd calls all on it:
def all(&block) @all ||= railties + engines + plugins @all.each(&block) if block @all endThis all method executes code on all the Rails::Railtie and Rails::Engine subclasses, retreived by the railties and engines methods defined right after all:
def railties @railties ||= ::Rails::Railtie.subclasses.map(&:new) end def engines @engines ||= ::Rails::Engine.subclasses.map(&:new) endBy default, the railties are:
- ActiveSupport::Railtie
- I18n::Railtie
- ActionDispatch::Railtie
- ActionController::Railtie
- ActiveRecord::Railtie
- ActionView::Railtie
- ActionMailer::Railtie
- ActiveResource::Railtie
- Rails::TestUnitRailtie
And these all descend from Rails::Railtie.
The default engines are [].
The plugins method it calls is a little more complex:
def plugins @plugins ||= begin plugin_names = (@config.plugins || [:all]).map { |p| p.to_sym } Plugin.all(plugin_names, @config.paths.vendor.plugins) end end@config.paths is defined in the Rails::Application::Configuration like this:
def paths @paths ||= begin paths = super paths.app.controllers << builtin_controller if builtin_controller paths.config.database “config/database.yml” paths.config.environment “config/environments”, :glob => “#{Rails.env}.rb” paths.log “log/#{Rails.env}.log” paths.tmp “tmp” paths.tmp.cache “tmp/cache” paths.vendor “vendor”, :load_path => true paths.vendor.plugins “vendor/plugins” if File.exists?(“#{root}/test/mocks/#{Rails.env}”) ActiveSupport::Deprecation.warn “\”RAILS_ROOT/test/mocks/#{Rails.env}\" won’t be added " << “automatically to load paths anymore in future releases” paths.mocks_path “test/mocks”, :load_path => true, :glob => Rails.env end paths end endWhen we call @config.paths.vendor.plugins it will return “vendor/plugins”.
If you’ve defined specific plugin requirements for your application in config/application.rb by using this code:
config.plugins = [:will_paginate, :by_star]or specific plugin loading using a similar statement such as this next one:
config.plugins = [:will_paginate, :by_star, :all]Then this is where the @config.plugins comes from. If you wish to load only certain plugins for your application, use the first example. If you wish to load certain plugins before the rest then the second example is what you would use.
If config.plugins is not defined then :all is specified in its place. Whatever the plugin_names is specified as, is passed to Plugin.all along with the path to the plugins, @config.path.vendor.plugins (which defaults to vendor/plugins):
def self.all(list, paths) plugins = [] paths.each do |path| Dir[“#{path}/*”].each do |plugin_path| plugin = new(plugin_path) next unless list.include?(plugin.name) || list.include?(:all) plugins << plugin end end plugins.sort_by do |p| [list.index(p.name) || list.index(:all), p.name.to_s] end endAs we can see here it will go through the paths and for every folder in vendor/plugins and initialize a new Rails::Plugin object for each:
def initialize(root) @name = File.basename(root).to_sym config.root = root endThis sets the plugin name to be the same name as the folder so the plugin located at vendor/plugins/by\_star_’s name is +bystar+. After that, the config object is initialized:
def config @config ||= Engine::Configuration.new endand the root of the plugin defined as that folder. The reasoning for defining a root is so that the initializer called load_init_rb has some place to look for this file:
initializer :load_init_rb, :before => :load_application_initializers do |app| file = Dir[“#{root}/{rails/init,init}.rb”].first config = app.config eval(File.read(file), binding, file) if file && File.file?(file) endA little more on that later, however.
If the plugin is not included in the list then it moves on to the next one. For all plugins included in the list (or if :all is specified in the list) they are put into a plugins local variable which is then sorted:
plugins.sort_by do |p| [list.index(p.name) || list.index(:all), p.name.to_s] endThe sort order is the same order as which they appear in the config.plugins setting, or in alphabetical order if there is no setting specified.
Now that we have our railties, engines, and plugins in a line we can finally get back to the all code:
def initializers railties.all { |r| initializers += r.initializers } endThis block will gather add the railties’ initializers to it.
The third line in this initializers method:
initializers += superThe super method it’s referring to is of course Rails::Engine.initializers, which isn’t defined on the class but, as we have seen before, is defined on the Rails::Railtie class it inherits from through the Rails::Initializable module. Therefore we can determine the initializers to be added are now the ones defined in Rails::Engine.
The final set of initializers in this chain are those in Rails::Finisher. This involves running any after initialize code, building the middleware stack and adding the route for rails/info/properties.
Now that we have all the initializers we can go back to the run_initializers in Rails::Initializable:
def run_initializers(*args) return if instance_variable_defined?(:@ran) initializers.each do |initializer| initializer.run(*args) end @ran = true endNow we finally have all the initializers we can go through them and call run:
def run(*args) @context.instance_exec(*args, &block) endYou may remember that the @context in this code is YourApp::Application and calling instance_exec on this class will make a new instance of it and execute the code within the &block passed to it. This code within the block is the code from all the initializers.
These initializers are the very first initializers that will be used to get your application going.
initializer :load_environment_config do require_environment! endThis quite simply makes a call to require_environment! which is defined like this in Rails::Application:
def require_environment! environment = config.paths.config.environment.to_a.first require environment if environment endWe’ve seen config.paths before when loading the plugins and they’re explained in more detail in the Bonus section at the end of this guide. config.enviroment for paths is defined like this:
paths.config.environment “config/environments”, :glob => “#{Rails.env}.rb”Rails.env was defined way back in the boot process when railties/lib/rails.rb was required:
module Rails
class << self
end
With ENV[“RAILS_ENV”] and ENV[“RACK_ENV”] not set to anything for our server booting process, this will default to “development”.
Therefore the path to this config file line would look like this with a substitution made:
paths.config.environment “config/environments”, :glob => “development.rb”This method returns a Path object (which acts as an Enumerable).
Back to require_environment now:
def require_environment! environment = config.paths.config.environment.to_a.first require environment if environment endAnd we’ve determined that config.paths.config.environment is Path object, and calling to_a on that object calls paths because it’s +alias+’d at the bottom of the Path class definition:
alias to_a paths def paths raise “You need to set a path root” unless @root.path result = @paths.map do |p| path = File.expand_path(p, @root.path) @glob ? Dir[File.join(path, @glob)] : path end result.flatten! result.uniq! result endThis returns an array of files according to our path and @glob which are config/environments and development.rb respectively, therefore we can determine that:
Dir[File.join(path, @glob)]will return an Array containing one element, “config/enviroments/development.rb”. Of course when we call first on this Array we’ll get the first element and because that exists, we now require “config/environments/development.rb”.
This file contains the following by default:
YourApp::Application.configure do- Settings specified here will take precedence over those in config/environment.rb
- In the development environment your application’s code is reloaded on
- every request. This slows down response time but is perfect for development
- since you don’t have to restart the webserver when you make code changes.
config.cache_classes = false
- Log error messages when you accidentally call methods on nil.
config.whiny_nils = true
- Show full error reports and disable caching
config.consider_all_requests_local = true
config.action_view.debug_rjs = true
config.action_controller.perform_caching = false
- Don’t care if the mailer can’t send
config.action_mailer.raise_delivery_errors = false
end
This configure method is an alias of class_eval on Rails::Application:
alias :configure :class_evaltherefore, the code inside of the configure is evaluated within the context of YourApp::Application.
The config object here is the same one that was set up when config/application.rb was loaded, therefore the methods called in this object will fall to the method_missing defined in Rails::Configuration::Shared:
def method_missing(name, *args, &blk) if name.to_s =~ config_key_regexp return $2 == ‘=’ ? options[$1] = args.first : options[$1] end super endThis time we are using methods ending in \=, so it will set the key in the options to be the value specified. The first couple of options, cache_classes, whiny_nils, consider_all_requests_local are just simple keys on the options. If you recall how options were setup then you may be able to work out how the remaining action_view, action_controller and action_mailer methods work.
Firstly, we’ll cover how config_key_regexp is defined:
def config_key_regexp bits = config_keys.map { |n| Regexp.escape(n.to_s) }.join(‘|’) /^(#{bits})(?:=)?$/ endAnd also config_keys:
def config_keys (Railtie.railtie_names + Engine.engine_names).map { |n| n.to_s }.uniq endconfig_keys in here returns:
[:active_support, :i18n, :action_dispatch, :action_view, :action_controller, :active_record, :action_mailer, :active_resource, :test_unit]With all of those keys coming from Railtie::railtie_names. If you’ve elected to not load some of the frameworks here they won’t be available as configuration keys, so you’ll need to remove them too.
Now a reminder of how the options key is defined:
def options @@options ||= Hash.new { |h,k| h[k] = ActiveSupport::OrderedOptions.new } endThe values for these framework keys are ActiveSupport::OrderedOptions objects, with the class defined like this:
module ActiveSupport #:nodoc: class OrderedOptions < OrderedHash def []=(key, value) super(key.to_sym, value) end def [](key) super(key.to_sym) end def method_missing(name, *args) if name.to_s =~ /(.*)=$/ self[$1.to_sym] = args.first else self[name] end end end endWe can determine when we call config.action_view.debug_rjs it’s falling back to the method_missing defined on ActiveSupport::OrderedOptions, which ends up either setting or retrieving a key. In this case because we’re using a setter, it will set the key for this hash. This completes the loading of config/environments/development.rb.
This initializer does exactly what it says:
initializer :load_all_active_support do require “active_support/all” unless config.active_support.bare endIf you don’t want this to happen you can specify the config.active_support.bare option to true in either config/application.rb or any of your environment files.
Remember earlier how we had all that stuff +eager_autoload+’d for Active Support?
initializer :preload_frameworks do require ‘active_support/dependencies’ ActiveSupport::Autoload.eager_autoload! if config.preload_frameworks endThis is where it gets loaded. The eager_autoload! method is defined like this:
def self.eager_autoload! @@autoloads.values.each { |file| require file } endWith @@autoloads being
- load_all_active_support
- preload_frameworks
- initialize_logger
- initialize_cache
- initialize_subscriber
- set_clear_dependencies_hook
- initialize_dependency_mechanism
Active Support
Active Support Initializers
- active_support.initialize_whiny_nils
- active_support.initialize_time_zone
I18n Initializers
- i18n.initialize
The I18n::Railtie also defines an after_initialize which we will return to later when discussing the initializers in detail.
Action Dispatch Initializers
- action_dispatch.prepare_dispatcher
Action Controller Initializers
- action_controller.logger
- action_controller.set_configs
- action_controller.initialize_framework_caches
- action_controller.set_helpers_path
Active Record Initializers
- active_record.initialize_time_zone
- active_record.logger
- active_record.set_configs
- active_record.log_runtime
- active_record.initialize_database_middleware
- active_record.load_observers
- active_record.set_dispatch_hooks
Action View Initializers *
- action_view.cache_asset_timestamps
Action Mailer Initializers *
- action_mailer.logger
- action_mailer.set_configs
- action_mailer.url_for
Active Resource Initializers
- active_resource.set_configs
Rails::Engine Initializers
- set_load_path
- set_autoload_paths
- add_routing_paths
The new method doesn’t exist, but in Ruby classes calling new on the class instantiates a new instance of that class and calls the instance method initialize on it. This method for Rails::Application goes like this:
def initialize require_environment Rails.application ||= self @route_configuration_files = [] endThis is not a crafty method like the previous ones, it just does as it says on the box:
def require_environment require config.environment_path rescue LoadError endThe config object here is actually another +delegate+’d method (along with routes), this time to self.class:
delegate :config, :routes, :to => :‘self.class’So the method call is actually self.class.config.
Defined back inside the class << self for Rails::Application, config makes a new Rails::Application::Configuration object and caches it in a variable called @config:
def config @config ||= Configuration.new(Plugin::Configuration.default) endThe Rails::Plugin::Configuration class may be a bit difficult to find at first, but if you look for plugin.rb in Rails, you’ll find it in railties/lib/rails/plugin.rb. In this file, we see the following:
module Rails class Plugin < Railtie … end endSo we note here that Rails::Plugin descends from Rails::Railtie and secondly we note that the class Configuration is not actually included in the Plugin class, but it is in the Railtie class!
We’ve now tracked down the Plugin::Configuration.default method to being Railtie::Configuration.default, which is defined like this in railties/lib/rails/configuration.rb:
class Railtie::Configuration def self.default @default ||= new end … endIn this case we have effectively seen that it’s doing Configuration.new(Configuration.new). I’ll explain why.
TODO: CLEAN THIS UP! This subclassing is only temporary and will probably not be separate in Rails 3. This is based solely off what the comment at the top of the Railtie::Configuration class says!
The first thing to note here is that this class is subclassed from Railtie::Configuration and therefore the method here is actually Railtie::Configuration.new. As mentioned previously, calling new will make a new object of this class and then call initialize on it, which is defined like this:
def initialize(base = nil) if base @options = base.options.dup @middleware = base.middleware.dup else @options = Hash.new { |h,k| h[k] = ActiveSupport::OrderedOptions.new } @middleware = self.class.default_middleware_stack end endThis method is not called with a base argument for Plugin::Configuration.default but it is for the Configuration.new wrapped around it. We’ll go for the internal one first, since that’s the order Rails loads them in.
This method is defined like this:
def self.default_middleware_stack ActionDispatch::MiddlewareStack.new.tap do |middleware| middleware.use(‘ActionDispatch::Static’, lambda { Rails.public_path }, :if => lambda { Rails.application.config.serve_static_assets }) middleware.use(‘::Rack::Lock’, :if => lambda { !ActionController::Base.allow_concurrency }) middleware.use(‘::Rack::Runtime’) middleware.use(‘ActionDispatch::ShowExceptions’, lambda { ActionController::Base.consider_all_requests_local }) middleware.use(‘ActionDispatch::Notifications’) middleware.use(‘ActionDispatch::Callbacks’, lambda { !Rails.application.config.cache_classes }) middleware.use(‘ActionDispatch::Cookies’) middleware.use(lambda { ActionController::Base.session_store }, lambda { ActionController::Base.session_options }) middleware.use(‘ActionDispatch::Flash’, :if => lambda { ActionController::Base.session_store }) middleware.use(lambda { Rails::Rack::Metal.new(Rails.application.config.paths.app.metals.to_a, Rails.application.config.metals) }) middleware.use(‘ActionDispatch::ParamsParser’) middleware.use(‘::Rack::MethodOverride’) middleware.use(‘::ActionDispatch::Head’) end endTo really understand this method we need to dig a little deeper, down into where ActionDispatch::MiddlewareStack.new is defined and what in particular it does for us.
ActionDispatch is our first foray outside of the railties gem, as this is actually defined in the actionpack part of Rails. The class definition is as important as the method:
module ActionDispatch class MiddlewareStack < Array … def initialize(*args, &block) super(*args) block.call(self) if block_given? end end endWhen it’s calling super here it’s actually calling initialize on the Array class and from this we can determine that an ActionDispatch::MiddlewareStack object is just an Array object with special powers. One of those special powers is the ability to take a block, and call it with self, meaning the block’s parameter is the object itself!
Previously we saw a chunk of code that I’ll re-show you stripped down:
def self.default_middleware_stack ActionDispatch::MiddlewareStack.new.tap do |middleware| middleware.use(‘ActionDispatch::Static’, lambda { Rails.public_path }, :if => lambda { Rails.application.config.serve_static_assets }) … end endAs explained in the previous section, we know that the new on ActionDispatch::MiddlewareStack takes a block and that block has one parameter which is the object itself. On this object we call the use method to include middleware into our application. The use method simply does this:
def use(*args, &block) middleware = Middleware.new(*args, &block) push(middleware) endWe’ll come back to this method later on.
This initialize method also is in a class who’s ancestry is important so once again I’ll show the ancestry and we’ll go up that particular chain:
module ActionController class Middleware < Metal … def initialize(app) super() @_app = app end end endHere our method calls super but with a difference: it’s passing in no arguments intentionally by putting the two brackets at the end. The method called here is therefore ActionController::Metal.initialize.
This is another subclassed class, this time from ActionController::AbstractController and I’m sure you can guess what that means:
class Metal < AbstractController::Base … def initialize(*) @_headers = {} super end endThe single * in the argument listing means we can accept any number of arguments, we just don’t care what they are.
This may be anti-climatic, but the initialize method here just returns an AbstractController::Base object:
- Initialize controller with nil formats.
def initialize #:nodoc:
@_formats = nil
end
Now we’re back to this method, from our foray into the depths of how Middleware.new works, we’ve showed that it is an instance of AbstractController::Base. Therefore it does
TODO: ELABORATE ON THIS SECTION, including explaining what all the pieces of middleware do. Then explain how the default_middleware_stack does what it does, whatever that is.
Now that the first call to this method is complete (Plugin::Configuration.default), we can move onto the second call. Here’s a refresher of what this method does:
def initialize(base = nil) if base @options = base.options.dup @middleware = base.middleware.dup else @options = Hash.new { |h,k| h[k] = ActiveSupport::OrderedOptions.new } @middleware = self.class.default_middleware_stack end endYou’ll note now that this method is being called now is Configuration.new(Plugin::Configuration.default) and with the argument, it’s going to perform differently than before, this time duplicating the options and middleware of the object it was passed.
TODO: Find out what purpose the @options and @middleware variables serve.
Finally, a Rails::Application::Configuration object will be returned. On this class there are a couple of +attr_accessor+s and +attr_writer+s defined:
attr_accessor :after_initialize_blocks, :cache_classes, :colorize_logging, :consider_all_requests_local, :dependency_loading, :load_once_paths, :logger, :metals, :plugins, :preload_frameworks, :reload_plugins, :serve_static_assets, :time_zone, :whiny_nils attr_writer :cache_store, :controller_paths, :database_configuration_file, :eager_load_paths, :i18n, :load_paths, :log_level, :log_path, :paths, :routes_configuration_file, :view_pathAlong with these are a lot of helper methods, and one of them is environment_path:
def environment_path “#{root}/config/environments/#{Rails.env}.rb” endNow that we have a Rails::Application::Configuration object for the config method, we call the environment_path which, as we’ve seen above, just requires the current environment file which in this case is config/environments/development.rb. If this file cannot be found, the LoadError require throws will be +rescue+’d and Rails will continue on its merry way.
In a standard Rails application we have this in our config/environments/development.rb file:
YourApp::Application.configure do- Settings specified here will take precedence over those in config/environment.rb
- In the development environment your application’s code is reloaded on
- every request. This slows down response time but is perfect for development
- since you don’t have to restart the webserver when you make code changes.
config.cache_classes = false
- Log error messages when you accidentally call methods on nil.
config.whiny_nils = true
- Show full error reports and disable caching
config.action_controller.consider_all_requests_local = true
config.action_view.debug_rjs = true
config.action_controller.perform_caching = false
- Don’t care if the mailer can’t send
config.action_mailer.raise_delivery_errors = false
end
It’s a little bit sneaky here, but configure is +alias+’d to class_eval on subclasses of Rails::Application which of course includes YourApp::Application. This means that the code inside the configure do block will be evaled within the context of YourApp::Application. The config method here is the one mentioned before: the Rails::Application::Configuration object. The methods on it should look familiar too: they’re the ones that had attr_accessor and attr_writer definitions.
The ones down the bottom, config.action_controller, config.action_view and config.action_mailer aren’t defined by attr_accessor or attr_writer, rather they’re undefined methods and therefore will trigger the method_missing on the Rails::Application::Configuration option.
The first method call in this file, this tells Rails to not cache the classes for every request. This means for every single request Rails will reload the classes of your application. If you have a lot of classes, this will slow down the request cycle of your application. This is set to false in the development environment, and true in the test & production environments.
If this is set to true, like it is here in the development environment, activesupport/whiny_nil will be +require+’d. Have you ever seen this error:
Called id for nil, which would mistakenly be 4 — if you really wanted the id of nil, use object_idOr perhaps this one?
You have a nil object when you didn’t expect it! You might have expected an instance of Array. The error occurred while evaluating nil.flatten!If you have, then this is activesupport/whiny_nil at work.
As mentioned before, the methods action_controller, action_view and action_mailer aren’t defined on the Rails::Application::Configuration object, rather they are caught by method_missing which does this:
def method_missing(name, *args, &blk) if name.to_s =~ config_key_regexp return $2 == ‘=’ ? @options[$1] = args.first : @options[$1] end super endWhilst this code is not obvious at first, a little bit of further explanation will help you understand. config_key_regexp is another method (a private one, like method_missing) defined here:
def config_key_regexp bits = config_keys.map { |n| Regexp.escape(n.to_s) }.join(‘|’) /^(#{bits})(?:=)?$/ endAs is config_keys:
def config_keys ([ :active_support, :action_view ] + Railtie.plugin_names).map { |n| n.to_s }.uniq endAha! There we’ve got mention of action_view, but what is in Railtie.plugin_names? Most likely in this case the other frameworks.
I’m going to show you two methods since the third one, self.plugin_name, calls the second one, self.plugins and they’re right after each other:
module Rails class Railtie def self.inherited(klass) @plugins ||= [] @plugins << klass unless klass == Plugin end def self.plugins @plugins end def self.plugin_names plugins.map { |p| p.plugin_name } end end endIn here we see that we get the plugin_names from a variable called @plugins… which we haven’t seen yet. Through the power of the wonderful inherited the @plugins variable is populated. inherited is called when a class inherits, or subclasses, from this class. Therefore we can determine that the other classes are probably inheriting or subclassing from Rails::Railtie.
Now that your application is fully initialized, it’s now ready to start serving requests.
For servers running through rails server you may recall that this uses Rails::Server which is a subclass of Rack::Server. Previously we covered the initialization process of Rack but not completely up to the point where the server was running. Now that’s what we’ll do. Back when the Rack::Server class was first covered there was a mention of the start method which we only touched on. It goes a little like this:
def start if options[:debug] $DEBUG = true require ‘pp’ p options[:server] pp wrapped_app pp app end if options[:warn] $-w = true end if includes = options[:include] $LOAD_PATH.unshift *includes end if library = options[:require] require library end daemonize_app if options[:daemonize] write_pid if options[:pid] server.run wrapped_app, options endWe were at the point of explaining what wrapped_app was before we dived into the Rails initialization process.Now that we have a wrapped_app we pass it as the first argument to server.run. server in this instance is defined like this:
def server @_server ||= Rack::Handler.get(options[:server]) || Rack::Handler.default endOur options Hash is still the default, and there is no server key set in default_options, so it will default to Rack::Handler.default. This code works like this:
def self.default(options = {})- Guess.
if ENV.include?(“PHP_FCGI_CHILDREN”) - We already speak FastCGI
options.delete :File
options.delete :Port
We don’t have PHP_FCGI_CHILDREN in our ENV, so it’s not going to be FastCGI. We also don’t have REQUEST_METHOD in there, so it’s not going to be CGI. If we have Mongrel installed it’ll default to that and then finally it’ll use WEBrick. For this, we’ll assume a bare-bones installation and assume WEBrick. So from this we can determine our default handler is Rack::Handler::WEBrick.
(side-note: Mongrel doesn’t install on 1.9. TODO: How do we format these anyway?)
This class is subclassed from WEBrick::HTTPServlet::AbstractServlet which is a class that comes with the Ruby standard library. This is the magical class that serves the requests and deals with the comings (requests) and goings (responses) for your server.
Rack::Server has handlers for the request and by default the handler for a rails server server is
The final line of config/environment.rb:
YourApp::Application.initialize!gets down to actually initializing the application!
TODO: Cover the other config.* methods in perhaps a “Bonus” section near the end. If they aren’t referenced in a config file they aren’t that important, right?
TODO: This belongs in the guide, I just don’t know where yet. Maybe towards the end, since this is really the “final” thing to be done before being able to serve requests.
def build_app(app) middleware[options[:environment]].reverse_each do |middleware| middleware = middleware.call(self) if middleware.respond_to?(:call) next unless middleware klass = middleware.shift app = klass.new(app, *middleware) end app endBecause we don’t have any middleware for our application, this returns the application itself( Guessing here!! TODO: Investigate if this is really the case.)
Now that we have an app instance, the last line in start calls server.run wrapped_app, options. We know what our app is, and that our options are just the default options, so what is server? server is this:
def server @_server ||= Rack::Handler.get(options[:server]) || Rack::Handler.default endSince we have default options, the server is obviously going to be Rack::Handler.default. The default method goes like this:
def self.default(options = {})- Guess.
if ENV.include?(“PHP_FCGI_CHILDREN”) - We already speak FastCGI
options.delete :File
options.delete :Port
The super method it references comes from Rails::Engine::Configuration which defines these paths:
def paths @paths ||= begin paths = Rails::Paths::Root.new(@root) paths.app “app”, :eager_load => true, :glob => “*” paths.app.controllers “app/controllers”, :eager_load => true paths.app.helpers “app/helpers”, :eager_load => true paths.app.models “app/models”, :eager_load => true paths.app.metals “app/metal” paths.app.views “app/views” paths.lib “lib”, :load_path => true paths.lib.tasks “lib/tasks”, :glob => “/.rake” paths.lib.templates “lib/templates” paths.config “config” paths.config.initializers “config/initializers”, :glob => “/.rb” paths.config.locales “config/locales”, :glob => “*.{rb,yml}” paths.config.routes “config/routes.rb” paths end endThis file is activesupport/lib/active_support/inflector/inflections.rb and defines the ActiveSupport::Inflector::Inflections class which defines the singularize, pluralize, humanize, tableize, titleize and classify methods as well as the code to defining how to work out the irregular, singular, plural and human versions of words. These methods are called irregular, singular, plural and human respectively, as is the Rails way.
This file is activesupport/lib/active_support/inflector/transliterate.rb and defines two methods, transliterate and parameterize. What transliterate does depends on your Ruby version. If you have something greater than 1.9 installed it will just print out a warning message using the Kernel#warn method (simply called using warn) reading “Ruby 1.9 doesn’t support Unicode normalization yet”. If you’re running something that’s not 1.9 it will attempt to convert “föö” to foo and if that fails then it’ll redefine it.
This file first makes a require to activesupport/lib/active_support/core_ext/string/multibyte.rb which then goes on to require activesupport/lib/active_support/multibyte.rb and that requires activesupport/core_ext/module/attribute_accessors.rb. The attribute_accessors.rb file is used to gain access to the mattr_accessor (module attribute accessor) method which is called in active_suport/multibyte.rb. Also in active_support/multibyte.rb there’s a couple of autoloaded classes:
module ActiveSupport #:nodoc:
module Multibyte
autoload :EncodingError, ‘active_support/multibyte/exceptions’
autoload :Chars, ‘active_support/multibyte/chars’
autoload :UnicodeDatabase, ‘active_support/multibyte/unicode_database’
autoload :Codepoint, ‘active_support/multibyte/unicode_database’
autoload :UCD, ‘active_support/multibyte/unicode_database’
…
end
end
There’s also these method definitions:
self.default_normalization_form = :kc- The proxy class returned when calling mb_chars. You can use this accessor to configure your own proxy
- class so you can support other encodings. See the ActiveSupport::Multibyte::Chars implementation for
- an example how to do this.
# - Example:
- ActiveSupport::Multibyte.proxy_class = CharsForUTF32
def self.proxy_class=(klass)
@proxy_class = klass
end
- Returns the currect proxy class
def self.proxy_class
@proxy_class ||= ActiveSupport::Multibyte::Chars
end
These methods are used in activesupport/lib/active_support/core_ext/string/multibyte.rb.
If we go back to activesupport/lib/active_support/core_ext/string/multibyte.rb_, this file makes a couple of extensions to the String class based on if your version of Ruby’s String class responds to the +forceencoding+ method. This method was introduced in Ruby 1.9. If you’re using 1.9 the methods are defined like this:
def mb_chars #:nodoc self end def is_utf8? #:nodoc case encoding when Encoding::UTF_8 valid_encoding? when Encoding::ASCII_8BIT, Encoding::US_ASCII dup.force_encoding(Encoding::UTF_8).valid_encoding? else false end endYou can see that calling mb_chars on a String instance in Ruby 1.9 will simply return that String object. String objects in Ruby 1.9 are already multibyte strings, so Rails does not need to do any conversion on them.
The second method, is_utf8? return true if the String object is of the UTF8 encoding or if it’s able to be forced into that encoding and false if it can’t force its encoding or if the encoding of the string is neither UTF8, ASCII_8BIT or US_ASCII.
If you’re using a Ruby version less than 1.9 there are 3 methods defined instead of 2, and they are defined like this:
def mb_chars if ActiveSupport::Multibyte.proxy_class.wants?(self) ActiveSupport::Multibyte.proxy_class.new(self) else self end end- Returns true if the string has UTF-8 semantics (a String used for purely byte resources is unlikely to have
- them), returns false otherwise.
def is_utf8?
ActiveSupport::Multibyte::Chars.consumes?(self)
end
As you can see, mb_chars is where the proxy_class method comes in handy. This will create a new instance of that class and pass in the String object in order to make it multibyte-compatible. In this case the new String object will be an instance of the ActiveSupport::Multibyte::Chars class. You can use ActiveSupport::Multibyte.proxy_class= to set this to be a different class if you’re that way inclined.
Here, is_utf8? calls a consumes method on the not-yet-loaded ActiveSupport::Multibyte::Chars class. The keen-eye would have seen this was specified as an auto-load earlier, so that is what is going to happen if we call this method or mb_chars. This means that it’ll require the file located at activesupport/lib/active_support/multibyte/chars.rb. This file includes activesupport/lib/active_support/string/access.rb which defines methods such as at, from, to, first and last. These methods will return parts of the string depending on what is passed to them and they are defined differently depending on if you’re using Ruby 1.9 or not. The second file included is activesupport/lib/active_support/string/behaviour.rb which defines a single method acts_like_string? on String which always returns true. This method is used through the acts_like? method which is passed a single argument representing the downcased and symbolised version of the class you want to know if it acts like. In this case the code would be acts_like?(:string).
The Chars class defines, along with consumes?, other methods such as the “spaceship” method <=>. This method is referenced by the methods defined in the included Comparable module and will return either -1, 0 or 1 depending on if the word is before, identical or after the compared word. For example, ‘é’.mb_chars <=> ‘ü’.mb_chars returns -1 as e comes before u in the alphabet. Other methods are the commonly used split, =~, insert and include?.
TODO: I feel this section would be better at the end of the guide as it breaks the flow.
This section is for all the common includes in the Railties.
This file is activesupport/lib/active_support/inflector.rb and makes a couple of requires out different files tasked with putting inflections in place:
require ‘active_support/inflector/inflections’ require ‘active_support/inflector/transliterate’ require ‘active_support/inflector/methods’ require ‘active_support/inflections’ require ‘active_support/core_ext/string/inflections’The files included here define methods for modifying strings, such as transliterate which will convert a Unicode string to its ASCII version, parameterize for making strings into url-safe versions, camelize for camel-casing a string such as string_other into StringOther and ordinalize converting a string such as 101 into 101st. More information about these methods can be found in the Active Support Core Extensions Guide. TODO: Link to AS Guide.
activesupport/lib/active_support/core_ext/module/delegation.rb defines the delegate method which can be used to delegate methods to other methods in your code. Take the following code example:
class Client < ActiveRecord::Base has_one :address delegate :address_line_1, :to => :address endThis defines an address_line_1 method which is defined as:
def address_line_1(*args, &block) address.send(:address_line_1, *args, &block) rescue NoMethodError if address.nil? raise “address_line_1 is delegated to address.address_line_1, but address is nil: #{client.inspect}” end endThe file, activesupport/lib/active_support/core_ext/class/attribute_accessors.rb_, defines the class accessor methods cattr_writer, cattr_reader and cattr_accessor. cattr_accessor defines a cattr_reader and +cattrwriter+ for the symbol passed in. These methods work by defining class variables when you call their dynamic methods.
Throughout the Railties there a couple of common includes. They are listed here for your convenience.
This file defines three methods attr_internal_reader, attr_internal_writer and attr_internal_accessor. These work very similar to the attr_reader, attr_writer and attr_accessor methods, except the variables they define begin with @_. This was done to ensure that they do not clash with variables used people using Rails, as people are less-likely to define say, @_request than they are to define @request. An example of where this method is used is for params in the ActionController::Metal class.
The activesupport/lib/active_support/ruby/shim.rb file requires methods that have been implemented in Ruby versions greater than 1.9. This is done so you can use Rails 3 on versions earlier than 1.9, such as 1.8.7. These methods are:
- Date#next_month
- Date#next_year
- DateTime#to_date
- DateTime#to_datetime
- DateTime#xmlschema
- Enumerable#group_by
- Enumerable#each_with_object
- Enumerable#none?
- Process#daemon
- String#ord
- Time#to_date
- Time.to_time
- Time.to_datetime
For more information see the Active Support Core Extensions guide TODO: link to relevant sections for each method.
And the REXML security fix detailed here]