RailTies is the set of components that wire together ActiveRecord, ActionController, and ActionView to form Rails. We will examine the two most important parts of RailTies: how Rails is initialized and how requests are processed.
The Rails::Configuration
class, defined in initializer.rb, holds the
configuration attributes that control Rails. It has several general
Rails attributes defined as attributes on the Configuration class, but there is a little
cleverness in the framework class stubs. The five class stubs
(action_controller, action_mailer,
action_view, active_resource, and active_record) act as proxies to the class
attributes of their respective Base
classes. In this way, the configuration statement:
config.action_controller.perform_caching = true
is the same as:
ActionController::Base.perform_caching = true
except with a unified configuration syntax.
Rails::Initializer is the
main class that handles setting up the Rails environment within Ruby.
Initialization is kicked off by
config/environment.rb, which contains the
block:
Rails::Initializer.run do |config|
# (configuration)
endRails::Initializer.run yields
a new Rails::Configuration object
to the block. Then run creates a
new Rails::Initializer object and
calls its process method, which
takes the following steps in order to initialize Rails:
check_ruby_version:
Ensures that Ruby1.8.2 or above (but not 1.8.3) is being
used.
set_load_path: Adds the
framework paths (RailTies, ActionPack, [20] ActiveSupport, ActiveRecord, Action Mailer, and
Action Web Service) and the application's load paths to the Ruby
load path. The framework is loaded from
vendor/rails or a location specified in
RAILS_FRAMEWORK_ROOT.
require_frameworks: Loads
each framework listed in the frameworks configuration option. If the
framework path was not specified in RAILS_FRAMEWORK_ROOT and it does not
exist in vendor/rails, Initializer will
assume the frameworks are installed as RubyGems.
set_autoload_paths: Sets
the autoload paths based on the values of the load_ paths and load_once_paths configuration variables.
These determine which paths will be searched to resolve unknown
constants. The load_paths
option is the same one that provided the application's load paths
in step 2.
load_environment: Loads
and evaluates the environment-specific (development, production,
or test) configuration file.
initialize_encoding: Sets
$KCODE to u for UTF-8 support
throughout Rails.
initialize_database: If
ActiveRecord is being used, sets up its database configuration and
connects to the database server.
initialize_logger: Sets
up the logger and sets the top-level constant RAILS_ DEFAULT_LOGGER to the instance.
If logger is specified in the
configuration, it is used. If not, a new logger is created and
directed to the log_path
specified. If that fails, a warning is displayed and logging is
redirected to standard error.
initialize_framework_logging: Sets the
logger for ActiveRecord, ActionController, and Action Mailer (if
they are being used) to the logger that was just set up.
initialize_framework_views: Sets the
view path for ActionController and Action Mailer to the value of
the view_path configuration
item.
initialize_dependency_mechanism: Sets
Dependencies.mechanism (which
determines whether to use require or load to load files) based on the setting
of the cache_classes
configuration item.
initialize_whiny_nils: If
the whiny_nils configuration
item is true, adds the WhinyNil
extensions (that complain when trying to call id or other methods on nil) to NilClass.
initialize_temporary_directories: Sets
ActionController's temporary session and cache directories if they
exist in the filesystem.
initialize_framework_settings:
Transforms the framework-specific configuration settings into
method calls on the frameworks' Base
classes. For example, consider the configuration
option:
config.active_record.schema_format = :sql
The config.active_record
object is an instance of Rails::OrderedOptions, which is
basically an ordered hash (ordered to keep the configuration
directives in order). During initialization, the initialize_framework_settings method
transforms it into the following:
ActiveRecord::Base.schema_format = :sql
This offers the advantage that the Configuration object doesn't have to be
updated every time a framework adds or changes a configuration
option.
add_support_load_paths:
Adds load paths for support functions. This function is currently
empty.
load_plugins: Loads the
plugins from paths in the plugin_paths configuration item (default
vendor/plugins). If a plugins configuration item is specified,
load those plugins respecting that load order. Plugins are loaded
close to the end of the process so that they can override any
already loaded component.
load_observers:
Instantiates ActiveRecord observers. This is done after plugins so
that plugins have an opportunity to modify the observer
classes.
initialize_routing: Loads
and processes the routes. Also sets the controller paths from the
controller_paths configuration
item.
after_initialize: Calls
any user-defined after_initialize callback. These
call-backs are defined in the configuration block by config.after_initialize { … }.
load_application_initializers: Loads all
Rubyfiles in RAILS_ROOT/config/ initializers
and any of its subdirectories. Old framework initialization that
may previouslyhave been contained in
config/environment.rb can now properly be
broken out into separate initializers.
Now the framework is ready to receive requests.
dispatcher.rb, fcgi_handler.rb, webrick_server.rb
The Dispatcher class is the
outside world's interface to Rails. Web servers dispatch a request to
Rails by calling Dispatcher.dispatch(cgi,
session_options, output). Rails processes the given CGI
request and presents the output to the given location (which defaults
to standard output). Rails can be reset by calling Dispatcher.reset_application! to process
multiple requests.
There are many ways to serve a Rails application. fcgi_handler.rb contains the FastCGI handler (RailsFCGIHandler) that shims between a FastCGI-speaking server (Apache, lighttpd, or even IIS) and Rails. webrick_server.rb is a server based on WEBrick that can serve Rails.
But the preferred application server for both development and
deployment is Zed Shaw's Mongrel. [21] Mongrel contains its own Rails handler that calls the
Dispatcher methods directly, using
its own CGI wrapper. Of course, more information can be found in
Mongrel's source itself.