diff options
Diffstat (limited to 'railties')
| -rw-r--r-- | railties/guides/files/stylesheets/main.css | 11 | ||||
| -rw-r--r-- | railties/guides/rails_guides/generator.rb | 37 | ||||
| -rw-r--r-- | railties/guides/rails_guides/helpers.rb | 4 | ||||
| -rw-r--r-- | railties/guides/source/action_view_overview.textile | 2 | ||||
| -rw-r--r-- | railties/guides/source/active_support_core_extensions.textile | 2 | ||||
| -rw-r--r-- | railties/guides/source/association_basics.textile | 2 | ||||
| -rw-r--r-- | railties/guides/source/credits.html.erb | 60 | ||||
| -rw-r--r-- | railties/guides/source/credits.textile.erb | 60 | ||||
| -rw-r--r-- | railties/guides/source/getting_started.textile | 4 | ||||
| -rw-r--r-- | railties/guides/source/index.html.erb | 150 | ||||
| -rw-r--r-- | railties/guides/source/index.textile.erb | 139 | ||||
| -rw-r--r-- | railties/guides/source/initialization.textile | 3334 | ||||
| -rw-r--r-- | railties/guides/source/layout.html.erb | 10 | ||||
| -rw-r--r-- | railties/guides/source/routing.textile | 145 | ||||
| -rw-r--r-- | railties/lib/rails/generators/migration.rb | 6 |
15 files changed, 3621 insertions, 345 deletions
diff --git a/railties/guides/files/stylesheets/main.css b/railties/guides/files/stylesheets/main.css index d377628d73..2fd0a2f37e 100644 --- a/railties/guides/files/stylesheets/main.css +++ b/railties/guides/files/stylesheets/main.css @@ -439,3 +439,14 @@ spurious blank area below with the box background. */ div.important p, div.caution p, div.warning p, div.note p, div.info p { margin-bottom: 0px; } + +/* Edge Badge +--------------------------------------- */ + +#edge-badge { + position: fixed; + right: 0px; + top: 0px; + z-index: 100; + border: none; +} diff --git a/railties/guides/rails_guides/generator.rb b/railties/guides/rails_guides/generator.rb index 670d2bc4db..d0873bfed5 100644 --- a/railties/guides/rails_guides/generator.rb +++ b/railties/guides/rails_guides/generator.rb @@ -11,11 +11,14 @@ require 'rails_guides/levenshtein' module RailsGuides class Generator - attr_reader :guides_dir, :source_dir, :output_dir + attr_reader :guides_dir, :source_dir, :output_dir, :edge + + GUIDES_RE = /\.(?:textile|html\.erb)$/ def initialize(output=nil) initialize_dirs(output) create_output_dir_if_needed + set_edge end def generate @@ -32,7 +35,11 @@ module RailsGuides def create_output_dir_if_needed FileUtils.mkdir_p(output_dir) - end + end + + def set_edge + @edge = ENV['EDGE_GUIDES'] == '1' + end def generate_guides guides_to_generate.each do |guide| @@ -42,7 +49,7 @@ module RailsGuides end def guides_to_generate - guides = Dir.entries(source_dir).grep(/\.textile(?:\.erb)?$/) + guides = Dir.entries(source_dir).grep(GUIDES_RE) ENV.key?("ONLY") ? select_only(guides) : guides end @@ -54,12 +61,12 @@ module RailsGuides end def copy_assets - FileUtils.cp_r(File.join(guides_dir, 'images'), File.join(output_dir, 'images')) - FileUtils.cp_r(File.join(guides_dir, 'files'), File.join(output_dir, 'files')) + FileUtils.cp_r(File.join(guides_dir, 'images'), output_dir) + FileUtils.cp_r(File.join(guides_dir, 'files'), output_dir) end def output_file_for(guide) - guide.sub(/\.textile(?:\.erb)?$/, '.html') + guide.sub(GUIDES_RE, '.html') end def generate?(source_file, output_file) @@ -71,13 +78,12 @@ module RailsGuides def generate_guide(guide, output_file) puts "Generating #{output_file}" File.open(File.join(output_dir, output_file), 'w') do |f| - view = ActionView::Base.new(source_dir) + view = ActionView::Base.new(source_dir, :edge => edge) view.extend(Helpers) - - if guide =~ /\.textile\.erb$/ - # Generate the erb pages with textile formatting - e.g. index/authors + + if guide =~ /\.html\.erb$/ + # Generate the special pages like the home. result = view.render(:layout => 'layout', :file => guide) - result = textile(result) else body = File.read(File.join(source_dir, guide)) body = set_header_section(body, view) @@ -87,8 +93,7 @@ module RailsGuides warn_about_broken_links(result) if ENV.key?("WARN_BROKEN_LINKS") end - - result = insert_edge_badge(result) if ENV.key?('INSERT_EDGE_BADGE') + f.write result end end @@ -126,7 +131,7 @@ module RailsGuides view.content_tag(:li, l.html_safe) end - children_ul = view.content_tag(:ul, children.join(" ").html_safe) + children_ul = children.empty? ? "" : view.content_tag(:ul, children.join(" ").html_safe) index << view.content_tag(:li, link.html_safe + children_ul.html_safe) end @@ -199,9 +204,5 @@ module RailsGuides end end end - - def insert_edge_badge(html) - html.sub(/<body[^>]*>/, '\&<img src="images/edge_badge.png" style="position:fixed; right:0px; top:0px; border:none; z-index:100"/>') - end end end diff --git a/railties/guides/rails_guides/helpers.rb b/railties/guides/rails_guides/helpers.rb index e05793d40e..bf99538696 100644 --- a/railties/guides/rails_guides/helpers.rb +++ b/railties/guides/rails_guides/helpers.rb @@ -9,7 +9,7 @@ module RailsGuides end result << content_tag(:dd, capture(&block)) - concat(result) + result end def lh(id, label = "Lighthouse Ticket") @@ -23,7 +23,7 @@ module RailsGuides result = content_tag(:img, nil, :src => image, :class => 'left pic', :alt => name) result << content_tag(:h3, name) result << content_tag(:p, capture(&block)) - concat content_tag(:div, result, :class => 'clearfix', :id => nick) + content_tag(:div, result, :class => 'clearfix', :id => nick) end def code(&block) diff --git a/railties/guides/source/action_view_overview.textile b/railties/guides/source/action_view_overview.textile index a517193cea..2fa89bb4c2 100644 --- a/railties/guides/source/action_view_overview.textile +++ b/railties/guides/source/action_view_overview.textile @@ -1079,7 +1079,7 @@ h4. JavaScriptHelper Provides functionality for working with JavaScript in your views. -Rails includes the Prototype JavaScript framework and the Scriptaculous JavaScript controls and visual effects library. If you wish to use these libraries and their helpers, make sure +<%= javascript_include_tag :defaults, :cache => true %>+ is in the HEAD section of your page. This function will include the necessary JavaScript files Rails generated in the public/javascripts directory. +Rails includes the Prototype JavaScript framework and the Scriptaculous JavaScript controls and visual effects library. If you wish to use these libraries and their helpers, make sure +<%= javascript_include_tag :defaults, :cache => true %>+ is in the HEAD section of your page. This function will include the necessary JavaScript files Rails generated in the public/javascripts directory. h5. button_to_function diff --git a/railties/guides/source/active_support_core_extensions.textile b/railties/guides/source/active_support_core_extensions.textile index 0a9374e028..a8410a8dd2 100644 --- a/railties/guides/source/active_support_core_extensions.textile +++ b/railties/guides/source/active_support_core_extensions.textile @@ -210,7 +210,7 @@ String.new.singleton_class # => #<Class:#<String:0x17a1d1c>> </ruby> WARNING: Fixnums and symbols have no singleton classes, +singleton_class+ -raises +TypeError+ on them. +raises +TypeError+ on them. Moreover, the singleton classes of +nil+, +true+, and +false+, are +NilClass+, +TrueClass+, and +FalseClass+, respectively. NOTE: Defined in +active_support/core_ext/object/singleton_class.rb+. diff --git a/railties/guides/source/association_basics.textile b/railties/guides/source/association_basics.textile index 757dce1f4e..4256466bec 100644 --- a/railties/guides/source/association_basics.textile +++ b/railties/guides/source/association_basics.textile @@ -417,7 +417,7 @@ h5. Creating Join Tables for +has_and_belongs_to_many+ Associations If you create a +has_and_belongs_to_many+ association, you need to explicitly create the joining table. Unless the name of the join table is explicitly specified by using the +:join_table+ option, Active Record creates the name by using the lexical order of the class names. So a join between customer and order models will give the default join table name of "customers_orders" because "c" outranks "o" in lexical ordering. -WARNING: The precedence between model names is calculated using the +<+ operator for +String+. This means that if the strings are of different lengths, and the strings are equal when compared up to the shortest length, then the longer string is considered of higher lexical precedence than the shorter one. For example, one would expect the tables "paper_boxes" and "papers" to generate a join table name of "papers_paper_boxes" because of the length of the name "paper_boxes", but it in fact generates a join table name of "paper_boxes_papers" (because the underscore '_' is lexicographically _less_ than 's' in common encodings). +WARNING: The precedence between model names is calculated using the +<+ operator for +String+. This means that if the strings are of different lengths, and the strings are equal when compared up to the shortest length, then the longer string is considered of higher lexical precedence than the shorter one. For example, one would expect the tables "paper_boxes" and "papers" to generate a join table name of "papers_paper_boxes" because of the length of the name "paper_boxes", but it in fact generates a join table name of "paper_boxes_papers" (because the underscore '_' is lexicographically _less_ than 's' in common encodings). Whatever the name, you must manually generate the join table with an appropriate migration. For example, consider these associations: diff --git a/railties/guides/source/credits.html.erb b/railties/guides/source/credits.html.erb new file mode 100644 index 0000000000..e026628e6a --- /dev/null +++ b/railties/guides/source/credits.html.erb @@ -0,0 +1,60 @@ +<% content_for :header_section do %> +<h2>Credits</h2> + +<p>We'd like to thank the following people for their tireless contributions to this project.</p> + +<% end %> + +<h3 class="section">Rails Documentation Team</h3> + +<%= author('Mike Gunderloy', 'mgunderloy') do %> + <p>Mike Gunderloy is a consultant with <a href="http://www.actionrails.com">ActionRails</a>. He brings 25 years of experience in a variety of languages to bear on his current work with Rails. His near-daily links and other blogging can be found at <a href="http://afreshcup.com">A Fresh Cup</a> and he <a href="http://twitter.com/MikeG1">twitters</a> too much.</p> +<% end %> + +<%= author('Pratik Naik', 'lifo') do %> + <p>Pratik Naik is a Ruby on Rails consultant with <a href="http://www.actionrails.com">ActionRails</a> and also a member of the <a href="http://rubyonrails.org/core">Rails core team</a>. He maintains a blog at <a href="http://m.onkey.org">has_many :bugs, :through => :rails</a> and has an active <a href="http://twitter.com/lifo">twitter account</a>.</p> +<% end %> + +<%= author('Xavier Noria', 'fxn', 'fxn.png') do %> + <p>Xavier has been into Rails since 2005, he is currently a Rails consultant. Xavier is Rails committer and enjoys combining his passion for Rails and his past life as a proofreader of math textbooks. Oh, he also <a href="http://twitter.com/fxn">tweets</a> and can be found everywhere as "fxn".</p> +<% end %> + +<h3 class="section">Rails Guides Designers</h3> + +<%= author('Jason Zimdars', 'jz') do %> + <p>Jason Zimdars is an experienced creative director and web designer who has lead UI and UX design for numerous websites and web applications. You can see more of his design and writing at <a href="http://www.thinkcage.com/">Thinkcage.com</a> or follow him on <a href="http://twitter.com/JZ">Twitter</a>.</p> +<% end %> + +<h3 class="section">Rails Guides Authors</h3> + +<%= author('Frederick Cheung', 'fcheung') do %> + <p>Frederick Cheung is Chief Wizard at Texperts where he has been using Rails since 2006. He is based in Cambridge (UK) and when not consuming fine ales he blogs at <a href="http://www.spacevatican.org">spacevatican.org</a>.</p> +<% end %> + +<%= author('Tore Darell', 'toretore') do %> + <p>Tore Darell is an independent developer based in Menton, France who specialises in cruft-free web applications using Ruby, Rails and unobtrusive JavaScript. His home on the internet is his blog <a href="http://tore.darell.no">Sneaky Abstractions</a>.</p> +<% end %> + +<%= author('Jeff Dean', 'zilkey') do %> + <p>Jeff Dean is a software engineer with <a href="http://pivotallabs.com">Pivotal Labs</a>.</p> +<% end %> + +<%= author('Cássio Marques', 'cmarques') do %> + <p>Cássio Marques is a Brazilian software developer working with different programming languages such as Ruby, JavaScript, CPP and Java, as an independent consultant. He blogs at <a href="http://cassiomarques.wordpress.com">/* CODIFICANDO */</a>, which is mainly written in Portuguese, but will soon get a new section for posts with English translation. +<% end %> + +<%= author('James Miller', 'bensie') do %> + <p>James Miller is a software developer for <a href="http://www.jk-tech.com">JK Tech</a> in San Diego, CA. Find me on GitHub, Gmail, Twitter, and Freenode as "bensie".</p> +<% end %> + +<%= author('Emilio Tagua', 'miloops') do %> + <p>Emilio Tagua —a.k.a. miloops— is an Argentinian entrepreneur, developer, open source contributor and Rails evangelist. Cofounder of <a href="http://eventioz.com">Eventioz</a>. He has been using Rails since 2006 and contributing since early 2008. Can be found at gmail, twitter, freenode, everywhere as "miloops".</p> +<% end %> + +<%= author('Heiko Webers', 'hawe') do %> + <p>Heiko Webers is the founder of <a href="http://www.bauland42.de">bauland42</a>, a German web application security consulting and development company focused on Ruby on Rails. He blogs at the <a href="http://www.rorsecurity.info">Ruby on Rails Security Project</a>. After 10 years of desktop application development, Heiko has rarely looked back.</p> +<% end %> + +<%= author('Mikel Lindsaar', 'raasdnil') do %> + <p>Mikel Lindsaar has been working with Rails since 2006 and is the author of the Ruby Mail gem and core contributor (he helped re-write Action Mailer's API). Mikel has a <a href="http://lindsaar.net/">blog</a> and <a href="http://twitter.com/raasdnil">tweets</a>. +<% end %> diff --git a/railties/guides/source/credits.textile.erb b/railties/guides/source/credits.textile.erb deleted file mode 100644 index 28c70f2b39..0000000000 --- a/railties/guides/source/credits.textile.erb +++ /dev/null @@ -1,60 +0,0 @@ -<% content_for :header_section do %> -h2. Credits - -p. We'd like to thank the following people for their tireless contributions to this project. - -<% end %> - -<h3 class="section">Rails Documentation Team</h3> - -<% author('Mike Gunderloy', 'mgunderloy') do %> - Mike Gunderloy is a consultant with "ActionRails":http://www.actionrails.com. He brings 25 years of experience in a variety of languages to bear on his current work with Rails. His near-daily links and other blogging can be found at "A Fresh Cup":http://afreshcup.com and he "twitters":http://twitter.com/MikeG1 too much. -<% end %> - -<% author('Pratik Naik', 'lifo') do %> - Pratik Naik is a Ruby on Rails consultant with "ActionRails":http://www.actionrails.com and also a member of the "Rails core team":http://rubyonrails.org/core. He maintains a blog at "has_many :bugs, :through => :rails":http://m.onkey.org and has an active "twitter account":http://twitter.com/lifo. -<% end %> - -<% author('Xavier Noria', 'fxn', 'fxn.png') do %> - Xavier has been into Rails since 2005, he is currently a Rails consultant. Xavier is president of the <a href="http://www.srug.org/">Spanish Ruby Users Group</a> and has been involved in Rails in several ways. He enjoys combining his passion for Rails and his past life as a proofreader of math textbooks. Oh, he also "tweets":http://twitter.com/fxn! -<% end %> - -<h3 class="section">Rails Guides Designers</h3> - -<% author('Jason Zimdars', 'jz') do %> - Jason Zimdars is an experienced creative director and web designer who has lead UI and UX design for numerous websites and web applications. You can see more of his design and writing at <a href="http://www.thinkcage.com/">Thinkcage.com</a> or follow him on <a href="http://twitter.com/JZ">Twitter</a>. -<% end %> - -<h3 class="section">Rails Guides Authors</h3> - -<% author('Frederick Cheung', 'fcheung') do %> - Frederick Cheung is Chief Wizard at Texperts where he has been using Rails since 2006. He is based in Cambridge (UK) and when not consuming fine ales he blogs at "spacevatican.org":http://www.spacevatican.org. -<% end %> - -<% author('Tore Darell', 'toretore') do %> - Tore Darell is an independent developer based in Menton, France who specialises in cruft-free web applications using Ruby, Rails and unobtrusive JavaScript. His home on the internet is his blog "Sneaky Abstractions":http://tore.darell.no. -<% end %> - -<% author('Jeff Dean', 'zilkey') do %> - Jeff Dean is a software engineer with "Pivotal Labs":http://pivotallabs.com. -<% end %> - -<% author('Cássio Marques', 'cmarques') do %> - Cássio Marques is a Brazilian software developer working with different programming languages such as Ruby, JavaScript, CPP and Java, as an independent consultant. He blogs at "/* CODIFICANDO */":http://cassiomarques.wordpress.com, which is mainly written in Portuguese, but will soon get a new section for posts with English translation. -<% end %> - -<% author('James Miller', 'bensie') do %> - James Miller is a software developer for "JK Tech":http://www.jk-tech.com in San Diego, CA. Find me on GitHub, Gmail, Twitter, and Freenode as bensie. -<% end %> - -<% author('Emilio Tagua', 'miloops') do %> - Emilio Tagua -- a.k.a. miloops -- is an Argentinian entrepreneur, developer, open source contributor and Rails evangelist. Cofounder of "Eventioz":http://eventioz.com. He has been using Rails since 2006 and contributing since early 2008. Can be found at gmail, twitter, freenode, everywhere as miloops. -<% end %> - -<% author('Heiko Webers', 'hawe') do %> - Heiko Webers is the founder of "bauland42":http://www.bauland42.de, a German web application security consulting and development company focused on Ruby on Rails. He blogs at the "Ruby on Rails Security Project":http://www.rorsecurity.info. After 10 years of desktop application development, Heiko has rarely looked back. -<% end %> - -<% author('Mikel Lindsaar', 'raasdnil') do %> - Mikel Lindsaar has been working with Rails since 2006 and is the author of the Ruby Mail gem and core contributor (he helped re-write ActionMailer's API). Mikel has a "blog":http://lindsaar.net/ and "tweets":http://twitter.com/raasdnil. -<% end %> diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile index c479c2fb20..9cc96f8205 100644 --- a/railties/guides/source/getting_started.textile +++ b/railties/guides/source/getting_started.textile @@ -545,7 +545,7 @@ This view iterates over the contents of the +@posts+ array to display content an * +link_to+ builds a hyperlink to a particular destination * +edit_post_path+ is a helper that Rails provides as part of RESTful routing. You'll see a variety of these helpers for the different actions that the controller includes. -NOTE. In previous versions of Rails, you had to use +<%=h post.name %>+ so that any HTML would be escaped before being inserted into the page. In Rails 3.0, this is now the default. To get unescaped HTML, you now use +<%= raw post.name %>+. +NOTE. In previous versions of Rails, you had to use +<%=h post.name %>+ so that any HTML would be escaped before being inserted into the page. In Rails 3.0, this is now the default. To get unescaped HTML, you now use +<%= raw post.name %>+. TIP: For more details on the rendering process, see "Layouts and Rendering in Rails":layouts_and_rendering.html. @@ -597,7 +597,7 @@ The +new.html.erb+ view displays this empty Post to the user: <%= link_to 'Back', posts_path %> </erb> -The +<%= render 'form' %>+ line is our first introduction to _partials_ in Rails. A partial is a snippet of HTML and Ruby code that can be reused in multiple locations. In this case, the form used to make a new post, is basically identical to a form used to edit a post, both have text fields for the name and title and a text area for the content with a button to make a new post or update the existing post. +The +<%= render 'form' %>+ line is our first introduction to _partials_ in Rails. A partial is a snippet of HTML and Ruby code that can be reused in multiple locations. In this case, the form used to make a new post, is basically identical to a form used to edit a post, both have text fields for the name and title and a text area for the content with a button to make a new post or update the existing post. If you take a look at +views/posts/_form.html.erb+ file, you will see the following: diff --git a/railties/guides/source/index.html.erb b/railties/guides/source/index.html.erb new file mode 100644 index 0000000000..8864b52325 --- /dev/null +++ b/railties/guides/source/index.html.erb @@ -0,0 +1,150 @@ +<% content_for :header_section do %> +<h2>Ruby on Rails Guides</h2> + +<% if @edge %> +<p> + These are <b>Edge Guides</b>, based on the current + <a href="http://github.com/rails/rails/tree/master">master branch</a>. +</p> +<p> + If you are looking for the ones for the stable version please check + <a href="http://guides.rubyonrails.org">http://guides.rubyonrails.org</a> instead. +</p> +<% end %> + +<p> + These guides are designed to make you immediately productive with Rails, + and to help you understand how all of the pieces fit together. +</p> + +<% end %> + +<% content_for :index_section do %> +<div id="subCol"> + <dl> + <dd class="warning">Rails Guides are a result of the ongoing <a href="http://hackfest.rubyonrails.org">Guides hackfest</a>, and a work in progress.</dd> + <dd class="ticket">Guides marked with this icon are currently being worked on. While they might still be useful to you, they may contain incomplete information and even errors. You can help by reviewing them and posting your comments and corrections at the respective Lighthouse ticket.</dd> + </dl> +</div> +<% end %> + +<h3>Start Here</h3> + +<dl> +<%= guide('Getting Started with Rails', 'getting_started.html') do %> + <p>Everything you need to know to install Rails and create your first application.</p> +<% end %> +</dl> + +<h3>Models</h3> + +<dl> +<%= guide("Rails Database Migrations", 'migrations.html') do %> + <p>This guide covers how you can use Active Record migrations to alter your database in a structured and organized manner.</p> +<% end %> + +<%= guide("Active Record Validations and Callbacks", 'activerecord_validations_callbacks.html') do %> + <p>This guide covers how you can use Active Record validations and callbacks.</p> +<% end %> + +<%= guide("Active Record Associations", 'association_basics.html') do %> + <p>This guide covers all the associations provided by Active Record.</p> +<% end %> + +<%= guide("Active Record Query Interface", 'active_record_querying.html') do %> + <p>This guide covers the database query interface provided by Active Record.</p> +<% end %> +</dl> + +<h3>Views</h3> + +<dl> +<%= guide("Layouts and Rendering in Rails", 'layouts_and_rendering.html') do %> + <p>This guide covers the basic layout features of Action Controller and Action View, including rendering and redirecting, using content_for blocks, and working with partials.</p> +<% end %> + +<%= guide("Action View Form Helpers", 'form_helpers.html', :ticket => 1) do %> + <p>Guide to using built in Form helpers.</p> +<% end %> +</dl> + +<h3>Controllers</h3> + +<dl> +<%= guide("Action Controller Overview", 'action_controller_overview.html') do %> + <p>This guide covers how controllers work and how they fit into the request cycle in your application. It includes sessions, filters, and cookies, data streaming, and dealing with exceptions raised by a request, among other topics.</p> +<% end %> + +<%= guide("Rails Routing from the Outside In", 'routing.html') do %> + <p>This guide covers the user-facing features of Rails routing. If you want to understand how to use routing in your own Rails applications, start here.</p> +<% end %> +</dl> + +<h3>Digging Deeper</h3> + +<dl> + +<%= guide("Rails on Rack", 'rails_on_rack.html') do %> + <p>This guide covers Rails integration with Rack and interfacing with other Rack components.</p> +<% end %> + +<%= guide("Rails Internationalization API", 'i18n.html') do %> + <p>This guide covers how to add internationalization to your applications. Your application will be able to translate content to different languages, change pluralization rules, use correct date formats for each country and so on.</p> +<% end %> + +<%= guide("Action Mailer Basics", 'action_mailer_basics.html', :ticket => 25) do %> + <p>This guide describes how to use Action Mailer to send and receive emails.</p> +<% end %> + +<%= guide("Testing Rails Applications", 'testing.html', :ticket => 8) do %> + <p>This is a rather comprehensive guide to doing both unit and functional tests in Rails. It covers everything from "What is a test?" to the testing APIs. Enjoy.</p> +<% end %> + +<%= guide("Securing Rails Applications", 'security.html') do %> + <p>This guide describes common security problems in web applications and how to avoid them with Rails.</p> +<% end %> + +<%= guide("Debugging Rails Applications", 'debugging_rails_applications.html') do %> + <p>This guide describes how to debug Rails applications. It covers the different ways of achieving this and how to understand what is happening "behind the scenes" of your code.</p> +<% end %> + +<%= guide("Performance Testing Rails Applications", 'performance_testing.html') do %> + <p>This guide covers the various ways of performance testing a Ruby on Rails application.</p> +<% end %> + +<%= guide("The Basics of Creating Rails Plugins", 'plugins.html', :ticket => 32) do %> + <p>This guide covers how to build a plugin to extend the functionality of Rails.</p> +<% end %> + +<%= guide("Configuring Rails Applications", 'configuring.html') do %> + <p>This guide covers the basic configuration settings for a Rails application.</p> +<% end %> + +<%= guide("Rails Command Line Tools and Rake tasks", 'command_line.html', :ticket => 29) do %> + <p>This guide covers the command line tools and rake tasks provided by Rails.</p> +<% end %> + +<%= guide("Caching with Rails", 'caching_with_rails.html', :ticket => 10) do %> + <p>Various caching techniques provided by Rails.</p> +<% end %> + +<%= guide("Contributing to Rails", 'contributing_to_rails.html') do %> + <p>Rails is not "somebody else's framework." This guide covers a variety of ways that you can get involved in the ongoing development of Rails.</p> +<% end %> +</dl> + +<h3>Release Notes</h3> + +<dl> +<%= guide("Ruby on Rails 3.0 Release Notes", '3_0_release_notes.html') do %> + <p>Release notes for Rails 3.0.</p> +<% end %> + +<%= guide("Ruby on Rails 2.3 Release Notes", '2_3_release_notes.html') do %> + <p>Release notes for Rails 2.3.</p> +<% end %> + +<%= guide("Ruby on Rails 2.2 Release Notes", '2_2_release_notes.html') do %> + <p>Release notes for Rails 2.2.</p> +<% end %> +</dl> diff --git a/railties/guides/source/index.textile.erb b/railties/guides/source/index.textile.erb deleted file mode 100644 index d7db81309f..0000000000 --- a/railties/guides/source/index.textile.erb +++ /dev/null @@ -1,139 +0,0 @@ -<% content_for :header_section do %> -h2. Ruby on Rails Guides - -These guides are designed to make you immediately productive with Rails, and to help you understand how all of the pieces fit together. There are two different versions of the Guides site, and you should be sure to use the one that applies to your situation: - -* "Current Release version":http://guides.rubyonrails.org - based on Rails 2.3 -* "Edge version":http://edgeguides.rubyonrails.org - based on the current Rails "master branch":http://github.com/rails/rails/tree/master - -<% end %> - -<% content_for :index_section do %> -<div id="subCol"> - <dl> - <dd class="warning">Rails Guides are a result of the ongoing "Guides hackfest":http://hackfest.rubyonrails.org and a work in progress.</dd> - <dd class="ticket">Guides marked with this icon are currently being worked on. While they might still be useful to you, they may contain incomplete information and even errors. You can help by reviewing them and posting your comments and corrections at the respective Lighthouse ticket.</dd> - </dl> -</div> -<% end %> - -h3. Start Here - -<dl> -<% guide('Getting Started with Rails', 'getting_started.html') do %> - Everything you need to know to install Rails and create your first application. -<% end %> -</dl> - -h3. Models - -<dl> -<% guide("Rails Database Migrations", 'migrations.html') do %> - This guide covers how you can use Active Record migrations to alter your database in a structured and organized manner. -<% end %> - -<% guide("Active Record Validations and Callbacks", 'activerecord_validations_callbacks.html') do %> - This guide covers how you can use Active Record validations and callbacks. -<% end %> - -<% guide("Active Record Associations", 'association_basics.html') do %> - This guide covers all the associations provided by Active Record. -<% end %> - -<% guide("Active Record Query Interface", 'active_record_querying.html') do %> - This guide covers the database query interface provided by Active Record. -<% end %> -</dl> - -h3. Views - -<dl> -<% guide("Layouts and Rendering in Rails", 'layouts_and_rendering.html') do %> - This guide covers the basic layout features of Action Controller and Action View, including rendering and redirecting, using content_for blocks, and working with partials. -<% end %> - -<% guide("Action View Form Helpers", 'form_helpers.html', :ticket => 1) do %> - Guide to using built in Form helpers. -<% end %> -</dl> - -h3. Controllers - -<dl> -<% guide("Action Controller Overview", 'action_controller_overview.html') do %> - This guide covers how controllers work and how they fit into the request cycle in your application. It includes sessions, filters, and cookies, data streaming, and dealing with exceptions raised by a request, among other topics. -<% end %> - -<% guide("Rails Routing from the Outside In", 'routing.html') do %> - This guide covers the user-facing features of Rails routing. If you want to understand how to use routing in your own Rails applications, start here. -<% end %> -</dl> - -h3. Digging Deeper - -<dl> - -<% guide("Rails on Rack", 'rails_on_rack.html') do %> - This guide covers Rails integration with Rack and interfacing with other Rack components. -<% end %> - -<% guide("Rails Internationalization API", 'i18n.html') do %> - This guide covers how to add internationalization to your applications. Your application will be able to translate content to different languages, change pluralization rules, use correct date formats for each country and so on. -<% end %> - -<% guide("Action Mailer Basics", 'action_mailer_basics.html', :ticket => 25) do %> - This guide describes how to use Action Mailer to send and receive emails. -<% end %> - -<% guide("Testing Rails Applications", 'testing.html', :ticket => 8) do %> - This is a rather comprehensive guide to doing both unit and functional tests in Rails. It covers everything from “What is a test?” to the testing APIs. Enjoy. -<% end %> - -<% guide("Securing Rails Applications", 'security.html') do %> - This guide describes common security problems in web applications and how to avoid them with Rails. -<% end %> - -<% guide("Debugging Rails Applications", 'debugging_rails_applications.html') do %> - This guide describes how to debug Rails applications. It covers the different ways of achieving this and how to understand what is happening "behind the scenes" of your code. -<% end %> - -<% guide("Performance Testing Rails Applications", 'performance_testing.html') do %> - This guide covers the various ways of performance testing a Ruby on Rails application. -<% end %> - -<% guide("The Basics of Creating Rails Plugins", 'plugins.html', :ticket => 32) do %> - This guide covers how to build a plugin to extend the functionality of Rails. -<% end %> - -<% guide("Configuring Rails Applications", 'configuring.html') do %> - This guide covers the basic configuration settings for a Rails application. -<% end %> - -<% guide("Rails Command Line Tools and Rake tasks", 'command_line.html', :ticket => 29) do %> - This guide covers the command line tools and rake tasks provided by Rails. -<% end %> - -<% guide("Caching with Rails", 'caching_with_rails.html', :ticket => 10) do %> - Various caching techniques provided by Rails. -<% end %> - -<% guide("Contributing to Rails", 'contributing_to_rails.html') do %> - Rails is not "somebody else's framework." This guide covers a variety of ways that you can get involved in the ongoing development of Rails. -<% end %> -</dl> - -h3. Release Notes - -<dl> -<% guide("Ruby on Rails 3.0 Release Notes", '3_0_release_notes.html') do %> - Release notes for Rails 3.0. -<% end %> - -<% guide("Ruby on Rails 2.3 Release Notes", '2_3_release_notes.html') do %> - Release notes for Rails 2.3. -<% end %> - -<% guide("Ruby on Rails 2.2 Release Notes", '2_2_release_notes.html') do %> - Release notes for Rails 2.2. -<% end %> -</dl> diff --git a/railties/guides/source/initialization.textile b/railties/guides/source/initialization.textile new file mode 100644 index 0000000000..590f9e1a81 --- /dev/null +++ b/railties/guides/source/initialization.textile @@ -0,0 +1,3334 @@ +h2. The Rails Initialization Process + +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. + +h3. Launch! + +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: + +<ruby> + 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 + + Rails::ScriptRailsLoader.exec_script_rails! + + railties_path = File.expand_path('../../lib', __FILE__) + $:.unshift(railties_path) if File.directory?(railties_path) && !$:.include?(railties_path) + + require 'rails/ruby_version_check' + Signal.trap("INT") { puts; exit } + + require 'rails/commands/application' +</ruby> + +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_. +SCRIPT_RAILS+ is simply _script/rails_. When +exec_script_rails+ 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: + +<ruby> + #!/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. + + ENV_PATH = File.expand_path('../../config/environment', __FILE__) + BOOT_PATH = File.expand_path('../../config/boot', __FILE__) + APP_PATH = File.expand_path('../../config/application', __FILE__) + + require BOOT_PATH + require 'rails/commands' +</ruby> + +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_. + +h3. Passenger + +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. + +h3. _config/boot.rb_ + +_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. + +<ruby> + # Use Bundler (preferred) + begin + require File.expand_path('../../.bundle/environment', __FILE__) + rescue LoadError + require 'rubygems' + require 'bundler' + Bundler.setup + end + +</ruby> + +h3. Bundled Rails (3.x) + + +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: + +<ruby> + source 'http://rubygems.org' + + gem 'rails', '3.0.0.beta1' + + # Bundle edge Rails instead: + # gem 'rails', :git => 'git://github.com/rails/rails.git' + + gem 'sqlite3-ruby', :require => 'sqlite3' + + # 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 + +</ruby> + +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.1.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: + +<ruby> + require 'rubygems' + require 'bundler' + Bundler.setup +</ruby> + ++Bundler.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_: + +<ruby> + 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 + end +</ruby> + + +The _.bundle/environment.rb_ file adds the _lib_ directory of all the gems specified in +Gemfile.lock+ to +$LOAD_PATH+. + +h3. Requiring Rails + +After _config/boot.rb_ is loaded, there's this +require+: + +<ruby> + require 'rails/commands' +</ruby> + +In this file, _railties/lib/rails/commands.rb_, there is a case statement for +ARGV.shift+: + +<ruby> + 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 +</ruby> + +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: + +<ruby> + require 'fileutils' + require 'optparse' + require 'action_dispatch' +</ruby> + +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. + +h4. +require 'active_support'+ + +_activesupport/lib/active_support.rb_ sets up +module ActiveSupport+: + +<ruby> + 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 + end +</ruby> + +This 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_: + + +<ruby> + require "active_support/inflector/methods" + + module ActiveSupport + module Autoload + @@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 + end +</ruby> + +Then it uses the method +eager_autoload+ also defined in _active_support/dependencies/autoload.rb_: + +<ruby> + def eager_autoload + old_eager, @@eager_autoload = @@eager_autoload, true + yield + ensure + @@eager_autoload = old_eager + end +</ruby> + +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: + +<ruby> + 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 + + autoload :SafeBuffer, "active_support/core_ext/string/output_safety" + autoload :TestCase + end + + autoload :I18n, "active_support/i18n" +</ruby> + +So we know the ones in +eager_autoload+ are eagerly loaded and it does this by storing them in an +@@autoloads+ hash object. This is then referenced by the +ActiveSupport::Autoload.eager_autoload!+ method which will go through and +require+ all the files specified. This method is called in the +preload_frameworks+ initializer and will be covered much later in this guide. + +The ones that are not +eager_autoload+'d are automatically loaded as they are called. + +Note: What 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. + +h4. +require 'action_dispatch'+ + +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: + +<ruby> + require 'rack' +</ruby> + +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: + +<ruby> + 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' +</ruby> + +h4. +require "rails/commands/server"+ + +Now that Rails has required Action Dispatch and it has required Rack, Rails can now go about defining the +Rails::Server+ class: + +<ruby> + module Rails + class Server < ::Rack::Server + + ... + + def initialize(*) + super + set_environment + end + + ... + + def set_environment + ENV["RAILS_ENV"] ||= options[:environment] + end + ... + end + end +</ruby> + +h4. +require "rails/commands"+ + +Back 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: + +<ruby> + def initialize(options = nil) + @options = options + end +</ruby> + +The +options+ method like this: + +<ruby> + def options + @options ||= parse_options(ARGV) + end +</ruby> + +The +parse_options+ method like this: + +<ruby> + 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") + + options.merge! opt_parser.parse! args + options + end +</ruby> + +And +default_options+ like this: + +<ruby> + def default_options + { + :environment => "development", + :pid => nil, + :Port => 9292, + :Host => "0.0.0.0", + :AccessLog => [], + :config => "config.ru" + } + end +</ruby> + +Here 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 +set_environment+: + +<ruby> + def set_environment + ENV["RAILS_ENV"] ||= options[:environment] + end +</ruby> + +From 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: + +<ruby> + require APP_PATH +</ruby> + ++APP_PATH+ was previously defined as _config/application.rb_ in the application's root, and so that is where Rails will go next. + +h4. +require APP_PATH+ + +This file is _config/application.rb_ in your application and makes two requires to begin with: + +<ruby> + require File.expand_path('../boot', __FILE__) + require 'rails/all' +</ruby> + +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: + +<ruby> + # 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" +</ruby> + +For the purposes of this guide, will will assume only: + +<ruby> + require 'rails/all' +</ruby> + +h4. +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: + +<ruby> + require 'rails' +</ruby> + +h4. +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. + +<ruby> + 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' +</ruby> + ++require 'pathname'+ requires the Pathname class which is used for returning a Pathname object for +Rails.root+ so that instead of doing: + +<ruby> + File.join(Rails.root, "app/controllers") +</ruby> + +You may do: + +<ruby> + Rails.root.join("app/controllers") +</ruby> + +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: + +<ruby> + require 'active_support' +</ruby> + +Is not ran as this was already required by _actionpack/lib/action_dispatch.rb_. + + +h4. +require 'active_support/core_ext/kernel/reporting'+ + +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.":http://api.rubyonrails.org/classes/Kernel.html + +For information on this file see the "Core Extensions" guide. TODO: link to guide. + +h4. +require 'active_support/core_ext/logger'+ + +For information on this file see the "Core Extensions" guide. TODO: link to guide. + +h4. +require 'rails/application'+ + +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_. + + +h4. +require 'rails/railties_path'+ + +This file serves one purpose: + +<ruby> + RAILTIES_PATH = File.expand_path(File.join(File.dirname(__FILE__), '..', '..')) +</ruby> + +Helpful, hey? One must wonder why they just didn't define it outright. + + +h4. +require 'rails/plugin'+ + +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. + +h4. +require 'rails/engine'+ + +This file requires _rails/railtie.rb_ which defines +Rails::Railtie+. + ++Rails::Engine+ defines a couple of 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: + +<ruby> + delegate :middleware, :paths, :root, :to => :config +</ruby> + +This 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+. + +h4. +require 'rails/railtie'+ + ++Rails::Railtie+ provides a method of classes to hook into Rails, providing them with methods to add generators, rake tasks and subscribers. Some of the more noticeable railties are ActionMailer, ActiveRecord and ActiveResource 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_. + +h4. +require 'rails/initializable'+ + +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 in +Rails::Engine+, +Rails::Application+ and +YourApp::Application+. In here we also see the class definition for +Rails::Initializer+, the class for all initializer objects. + +h4. +require 'rails/configuration'+ + +The +Rails::Configuration+ module sets up shared configuration for applications, engines and plugins alike. + +At the top of this file _rails/paths.rb_ and _rails/rack.rb_ are +require+'d. + +TODO: Expand on this section. + +h4. +require 'rails/paths'+ + +TODO: Figure out the usefulness of this code. Potentially used for specifying paths to applications/engines/plugins? + +h4. +require 'rails/rack'+ + +This file sets up some +autoload+'d modules for Rails::Rack. + +h4. +require 'rails/version'+ + +Now we're back to _rails.rb_. The line after +require 'rails/application'+ in _rails.rb_ is: + +<ruby> + require 'rails/version' +</ruby> + +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+. + +h4. +require 'rails/deprecation'+ + +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 (explained previously) are now +Rails.env+, +Rails.root+ and +Rails.logger+ respectively. + +h4. +require 'rails/log_subscriber'+ + +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. + +h4. +require 'rails/ruby_version_check'+ + +This file ensures that you're running a minimum of 1.8.7. If you're running an older version, it will tell you: + +<pre> + Rails requires Ruby version 1.8.7 or later. + You're running [your Ruby version here]; please upgrade to continue. +</pre> + +h4. +require 'activesupport/railtie'+ + +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. + + +h4. +require 'action_dispatch/railtie'+ + +This file first makes a require out to the _action_dispatch_ file which is explained in the ActionDispatch Railtie section, next it makes a require to _rails_ which is _railties/lib/rails.rb_ which is already required. + +This file then extends the +ActionDispatch+ module defined when we called +require "action_dispatch"+ like this: + +<ruby> + module ActionDispatch + class Railtie < Rails::Railtie + railtie_name :action_dispatch + + # 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 +</ruby> + +This defines just the one initializer: +action_dispatch.prepare_dispatcher+. More on this later. TODO: link when written + +h4. Return to _rails/all.rb_ + +Now that we've covered the extensive process of what the first line does in this file, lets cover the remainder: + +<ruby> + %w( + active_record + action_controller + action_mailer + active_resource + rails/test_unit + ).each do |framework| + begin + require "#{framework}/railtie" + rescue LoadError + end + end +</ruby> + +h4. ActiveRecord Railtie + +The ActiveRecord Railtie takes care of hooking ActiveRecord into Rails. This depends on ActiveSupport, ActiveModel and Arel. From ActiveRecord's readme: + +TODO: Quotify. + +<text> + 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. +</text> + +h5. +require "active_record/railtie"+ + +The _activerecord/lib/active_record/railtie.rb_ file defines the Railtie for ActiveRecord. + +This file first requires ActiveRecord, the _railties/lib/rails.rb_ file which has already been required and so will be ignored, and the ActiveModel Railtie: + +<ruby> + require "active_record" + require "rails" + require "active_model/railtie" +</ruby> + +ActiveModel's Railtie is covered in the next section. TODO: Section. + +h5. +require "active_record"+ + +TODO: Why are +activesupport_path+ and +activemodel_path+ defined here? + +The first three requires require ActiveSupport, ActiveModel and ARel in that order: + +<ruby> + require 'active_support' + require 'active_model' + require 'arel' +</ruby> + + +h5. +require "active_support"+ + +This was loaded earlier by _railties/lib/rails.rb_. This line is here as a safeguard for when ActiveRecord is loaded outside the scope of Rails. + +h5. +require "active_model"+ + +TODO: Again with the +activesupport_path+! + +Here we see another +require "active_support"+ this is again, a safeguard for when ActiveModel is loaded outside the scope of Rails. + +This file defines a few +autoload+'d modules for ActiveModel, requires +active_support/i18n+ and adds the default translation file for ActiveModel to +I18n.load_path+. + +The +require 'active_support/i18n'+ just loads I18n and adds ActiveSupport's default translations file to +I18n.load_path+ too: + +<ruby> + require 'i18n' + I18n.load_path << "#{File.dirname(__FILE__)}/locale/en.yml +</ruby> + + +h5. +require "arel"+ + +This file in _arel/lib/arel.rb_ loads a couple of ActiveSupport things first: + +<ruby> + require 'active_support/inflector' + require 'active_support/core_ext/module/delegation' + require 'active_support/core_ext/class/attribute_accessors' +</ruby> + +These files are explained in the "Common Includes" section. + +h5. +require 'arel'+ + +Back in _arel/lib/arel.rb_, the next two lines require ActiveRecord parts: + +<ruby> + require 'active_record' + require 'active_record/connection_adapters/abstract/quoting' +</ruby> + +Because we're currently loading _active_record.rb_, it skips right over it. + +h5. +require 'active_record/connection_adapters/abstract/quoting'+ + +_activerecord/lib/active_record/connection_adapters/abstract/quoting.rb_ defines methods used for quoting fields and table names in ActiveRecord. + +TODO: Explain why this is loaded especially. + +h5. +require 'active_record'+ + +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 ActiveRecord 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 ActiveRecord which are only for if a record is invalid or non-unique. + +h5. +require 'rails'+ + +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. + +h5. +require 'active_model/railtie'+ + +This is covered in the ActiveModel Railtie section. TODO: link there. + +h5. +require 'action_controller/railtie'+ + +This is covered in the ActionController Railtie section. TODO: link there. + +h5. The ActiveRecord Railtie + +Inside the ActiveRecord Railtie the +ActiveRecord::Railtie+ class is defined: + +<ruby> + module ActiveRecord + class Railtie < Rails::Railtie + + ... + end + end +</ruby> + +TODO: 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. + + +h4. ActiveModel Railtie + +This Railtie is +require+'d by ActiveRecord's Railtie. + +From the ActiveModel readme: + +<text> + 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. +</text> + + +h5. +require "active_model/railtie"+ + +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. + +<ruby> + require "active_model" + require "rails" +</ruby> + +h5. +require "active_model"+ + +ActiveModel depends on ActiveSupport 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 ActiveModel, such as "is not included in the list" and "is reserved". + +h4. Action Controller Railtie + +The ActionController 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. + +h5. +require 'action_controller/railtie'+ + +This first makes a couple of requires: + +<ruby> + require "action_controller" + require "rails" + require "action_view/railtie" +</ruby> + +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 ActionView Railtie section. + +h5. +require 'action_controller+ + +This file, _actionpack/lib/action_controller.rb_, defines the ActionController 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. + +h5. +require 'abstract_controller'+ + ++AbstractController+ provides the functionality of TODO. + +This file is in _actionpack/lib/abstract_controller.rb_ and begins by attempting to add the path to ActiveSupport 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: + +<ruby> + 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' +</ruby> + +After these require calls the +AbstractController+ module is defined with some standard +autoload+'d classes. + + +h5. +require 'active_support/ruby/shim'+ + +This file is explained in the "Common Includes" section beneath. + +h5. +require 'active_support/dependencies/autoload+ + +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. + +h5. +require 'active_support/core_ext/module/attr_internal'+ + +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 ActiveSupport Extensions guide. + +h5. +require 'active_support/core_ext/module/delegation'+ + +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!). + +h5. +require 'action_controller'+ + +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 ActiveRecord 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+: + +<ruby> + 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 + end +</ruby> + +This 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 ActiveSupport goes looking for them it will look in that file. + +At the end of this file there are a couple more requires: + +<ruby> + # All of these simply register additional autoloads + require 'action_view' + require 'action_controller/vendor/html-scanner' + + # Common ActiveSupport 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' +</ruby> + +h5. +require 'action_view'+ + +This is best covered in the ActionView Railtie section, so skip there by TODO: Link / page? + +h5. +require 'action_controller/vendor/html-scanner'+ + +TODO: What is the purpose of this? Find out. + +h5. +require 'active_support/concern'+ + +TODO: I can kind of understand the purpose of this.. need to see where @_dependencies is used however. + +h5. +require 'active_support/core_ext/class/attribute_accessors'+ + +This file defines, as the path implies, attribute accessors for class. These are +cattr_reader+, +cattr_writer+, +cattr_accessor+. + +h5. +require 'active_support/core_ext/load_error'+ + +The ActiveSupport Core Extensions (TODO: LINK!) guide has a great coverage of what this file precisely provides. + +h5. +require 'active_support/core_ext/module/attr_internal'+ + +This file is explained in the "Core Extension" guide. + +This file was required through the earlier _abstract_controller.rb_ require. + +h5. +require 'active_support/core_ext/module/delegation'+ + +This file is explained in the "Common Includes" section. + +This file was required earlier by Arel and so is not required again. + +h5. +require 'active_support/core_ext/name_error'+ + +This file includes extensions to the +NameError+ class, providing the +missing_name+ and +missing_name?+ methods. For more information see the ActiveSupport extensions guide. + +h5. +require 'active_support/inflector'+ + +This file is explained in the "Common Includes" section. + +This file was earlier required by Arel and so is not required again. + +h5. ActionController Railtie + +So now we come back to the ActionController Railtie with a couple more requires to go before +ActionController::Railtie+ is defined: + +<ruby> + require "action_view/railtie" + require "active_support/core_ext/class/subclasses" + require "active_support/deprecation/proxy_wrappers" + require "active_support/deprecation" +</ruby> + +As explained previously the +action_view/railtie+ file will be explained in the ActionView Railtie section. TODO: link to it. + +h5. +require 'active_support/core_ext/class/subclasses'+ + +For an explanation of this file _activesupport/lib/active_support/core_ext/class/subclasses_, see the ActiveSupport Core Extension guide. + +h5. +require 'active_support/deprecation/proxy_wrappers'+ + +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 ActiveSupport, you too can use the +DeprecationProxy+ class (and it's subclasses) too. + + +h6. +DeprecationProxy+ + +This class is used only in _railties/lib/rails/deprecation.rb_, loaded further on in the initialization process. It's used in this way: + +<ruby> + 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).new +</ruby> + +There 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. + +h6. +DeprecatedObjectProxy+ + +This is used in one place _actionpack/lib/action_controller/railtie.rb_, which you may remember is how we got to the +DeprecationProxy+ section: + +<ruby> + ActiveSupport::Deprecation::DeprecatedObjectProxy.new(app.routes, message) +</ruby> + +This makes more sense in the wider scope of the initializer: + +<ruby> + 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 + end +</ruby> + ++ActionController::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. + + +h6. +DeprecatedInstanceVariableProxy+ + +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 ActiveSupport. + +h6. +DeprecatedConstantProxy+ + +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: + +<ruby> + CircularReferenceError = Deprecation::DeprecatedConstantProxy.new('ActiveSupport::JSON::CircularReferenceError', Encoding::CircularReferenceError) +</ruby> + + +Now when you reference +ActiveSupport::JSON::CircularReferenceError+ you'll receive a warning: + +<text> + ActiveSupport::JSON::CircularReferenceError is deprecated! Use Encoding::CircularReferenceError instead. +</text> + +h5. +require "active_support/deprecation"+ + +This re-opens the +ActiveSupport::Deprecation+ module which was already defined by our deprecation proxies. Before this happens however we have 4 requires: + +<ruby> + require 'active_support/deprecation/behaviors' + require 'active_support/deprecation/reporting' + require 'active_support/deprecation/method_wrappers' + require 'active_support/deprecation/proxy_wrappers' +</ruby> + +The remainder of this file goes about setting up the +silenced+ and +debug+ accessors: + +<ruby> + 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 +</ruby> + +h5. +require "active_support/deprecation/behaviors"+ + +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: + +<ruby> + # 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 + } + } +</ruby> + +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 ActiveSupport can pass arguments to the +call+ method we call on it when ActiveSupport +warn+. + +h5. +require 'active_support/deprecation/reporting'+ + +This file defines further extensions to the +ActiveSupport::Deprecation+ module, including the +warn+ method which is used from ActiveSupport'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: + +<ruby> + ActiveSupport::Deprecation.silence do + puts "YOU CAN FIND ME HERE: #{RAILS_ROOT}" + end +</ruby> + +TODO: may have to correct this example. + +h5. +require 'active_support/deprecation/method_wrappers'+ + +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: + +<ruby> + 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 +</ruby> + +h5. +require 'action_controller/railtie'+ + +Inside +ActionController::Railtie+ there are another two requires: + +<ruby> + require "action_controller/railties/log_subscriber" + require "action_controller/railties/url_helpers" +</ruby> + + +h5. +require 'action_controller/railties/log_subscriber'+ + ++ActionController::Railties::LogSubscriber+ inherits from +Rails::LogSubscriber+ and defines methods for logging such things as action processing and file sending. + +h5. +require 'action_controller/railties/url_helpers'+ + +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. + +h5. ActionController Railtie + +After these requires it deprecates a couple of ex-ActionController 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 + +h4. ActionView Railtie + +The ActionView 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. + +h5. +require 'action_view/railtie'+ + +The Railtie is defined in a file called _actionpack/lib/action_view/railtie.rb_ and initially makes a call to +require 'action_view'+. + +h5. +require 'action_view'+ + +Here again we have the addition of the path to ActiveSupport to the load path attempted, but because it's already in the load path it will not be added. Similarly, we have two requires: + +<ruby> + require 'active_support/ruby/shim' + require 'active_support/core_ext/class/attribute_accessors' +</ruby> + +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): + +<ruby> + require 'action_pack/version' +</ruby> + +the _version_ file contains this code (comments stripped): + +<ruby> + module ActionPack #:nodoc: + module VERSION #:nodoc: + MAJOR = 3 + MINOR = 0 + TINY = "0.beta1" + + STRING = [MAJOR, MINOR, TINY].join('.') + end + end +</ruby> + +TODO: Why?! + +This file goes on to define the +ActionView+ module and its +autoload+'d modules and then goes on to make two more requires: + +<ruby> + require 'active_support/core_ext/string/output_safety' + require 'action_view/base' +</ruby> + +h5. +require 'active_support/core_ext/string/output_safety'+ + +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. + +h5. +require 'action_view/base'+ + +This file initially makes requires to the following files: + +<ruby> + require 'active_support/core_ext/module/attr_internal' + require 'active_support/core_ext/module/delegation' + require 'active_support/core_ext/class/attribute' +</ruby> + +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: + +<ruby> + include Helpers, Rendering, Partials, Layouts, ::ERB::Util, Context +</ruby> + +h5. +ActionView::Helpers+ + +This module, from _actionpack/lib/action_view/helpers.rb_, initially sets up the +autoload+'s for the various +ActionView::Helpers+ modules (TODO: mysteriously not using +autoload_under+). This also sets up a +ClassMethods+ module which is included automatically into wherever +ActionView::Helpers+ is included by defining a +self.included+ method: + +<ruby> + def self.included(base) + base.extend(ClassMethods) + end + + module ClassMethods + include SanitizeHelper::ClassMethods + end +</ruby> + +Inside 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: + +<ruby> + benchmark("potentially long running thing") do + Post.count + end +</ruby> + +The "documentation":http://api.rails.info/classes/ActiveSupport/Benchmarkable.html#M000607 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. + +h5. +ActionView::Rendering+ + +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. + +h5. +ActionView::Partials+ + +This module, from _actionpack/lib/action_view/render/partials.rb_, defines +ActionView::Partials::PartialRenderer+ which you can probably guess is used for rendering partials. + +h5. +ActionView::Layouts+ + +This module, from _actionpack/lib/action_view/render/layouts.rb_, defines +ActionView::Layouts+ which defines methods such as +find_layout+ for locating layouts. + +h5. +ERB::Util+ + +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. + +h5. +ActionView::Context+ + +TODO: Not entirely sure what this is all about. Something about the context of view rendering... can't work it out. + +h5. ActionView Railtie + +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: + + +<ruby> + 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 + end +</ruby> + +TODO: Explain LogSubscriber. + +The 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 +cache_classes+ is set to false in any of your application's configuration. TODO: Elaborate. + +WARNING: EVERYTHING AFTER THIS POINT HAS NOT BEEN UPDATED TO REFLECT THE RAILS 3 BETA RELEASE. HERE BE DRAGONS. DANGER, WILL ROBINSON, DANGER. CONTINUE AT YOUR OWN PERIL!!! + + + +h4. ActionMailer Railtie + +h4. ActiveResource Railtie + +h4. ActionDispatch Railtie + +h5. +require 'action_dispatch'+ + +This file, _lib/actionpack/lib/action_dispatch.rb_ is initially required through the _railties/lib/rails.rb_ file earlier on in the initilization process. We will cover again what it does. + + requires +ActionDispatch+ which is responsible for serving the requests and responses for your application. In it there are three initial requires: + +<ruby> + require 'active_support' + require 'active_support/dependencies/autoload' + + require 'rack' +</ruby> + +At this point in the application _active_support_ and _active_support/dependencies/autoload_ have already been loaded (TODO: link to sections) and so it's up the last require of _rack_. + +h3. Common Includes + +This section is for all the common includes in the Railties. + +h4. +require 'active_support/inflector'+ + +This file is _activesupport/lib/active_support/inflector.rb_ and makes a couple of requires out different files tasked with putting inflections in place: + +<ruby> + 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' +</ruby> + +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 ActiveSupport Guide. TODO: Link to AS Guide. + +h4. +require 'active_support/core_ext/module/delegation'+ + +_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: + +<ruby> + class Client < ActiveRecord::Base + has_one :address + + delegate :address_line_1, :to => :address + end +</ruby> + +This defines an +address_line_1+ method which is defined as: + +<ruby> + 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 + end +</ruby> + +h4. +require 'active_support/core_ext/class/attribute_accessors'+ + +The 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 +cattr_writer+ 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. + +h4. +require 'active_support/core_ext/module/attr_internal+ + +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. + +h4. +require 'active_support/ruby/shim'+ + +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 ActiveSupport Extensions guide TODO: link to relevant sections for each method. + +And "the REXML security fix detailed here":[http://weblog.rubyonrails.org/2008/8/23/dos-vulnerabilities-in-rexml] + +h3. Firing it up! + +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+: + +<ruby> + when 's', 'server' + require 'rails/commands/server' + Dir.chdir(ROOT_PATH) + Rails::Server.start +</ruby> + +The 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: + +<ruby> + 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] + end +</ruby> + +We 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. + +h3. Racking it up! + + +This +Rack::Server.start+ method is defined like this: + +<ruby> + def self.start + new.start + end +</ruby> + ++new+ as you know calls +initialize+ in a class, and that is defined like this: + +<ruby> + def initialize(options = nil) + @options = options + end +</ruby> + +And then +options+, which are the options referenced by the +start+ method in +Rails::Server+. + +<ruby> + def options + @options ||= parse_options(ARGV) + end +</ruby> + +And +parse_options+: + +<ruby> + 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") + + options.merge! opt_parser.parse! args + options + end +</ruby> + +And +default_options+: + +<ruby> + def default_options + { + :environment => "development", + :pid => nil, + :Port => 9292, + :Host => "0.0.0.0", + :AccessLog => [], + :config => "config.ru" + } + end +</ruby> + +Finally! We've arrived at +default_options+ which leads into our next point quite nicely. After the object has been +initialize+'d, +start+ is called: + +<ruby> + 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 + end +</ruby> + +We'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: + +<ruby> + def wrapped_app + @wrapped_app ||= build_app app + end +</ruby> + +and +build_app+'s first and only argument is +app+ which is defined like this: + + +<ruby> + 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 + end +</ruby> + ++options+ 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_: + +<ruby> + 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 + end +</ruby> + +First 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: + +<ruby> + #\\ -E production + # This file is used by Rack-based servers to start the application. + + require ::File.expand_path('../config/environment', __FILE__) + run YourApp::Application.instance + +</ruby> + +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. + +h3. _config/environment.rb_ + +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. + +<ruby> + # Load the rails application + require File.expand_path('../application', __FILE__) + + # Initialize the rails application + YourApp::Application.initialize! + +</ruby> + +As you can see, there's a require in here for _config/application.rb_, and this file looks like this: + + +<ruby> + 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 +</ruby> + +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. + + +h3. Rails Initialization Process + +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. + +h3. +Rails::Application+ + +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+: + +<ruby> + def inherited(base) + raise "You cannot have more than one Rails::Application" if Rails.application + super + Rails.application = base.instance + end +</ruby> + +This goes up the chain by using +super+ to calling +Rails::Engine.inherited+: + +<ruby> + 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 + end +</ruby> + ++called_from+ references where this code was called from. This is covered later on in the "Bootstrap Initializers" section. + +Which then calls +Rails::Railtie.inherited+: + +<ruby> + def inherited(base) + unless abstract_railtie?(base) + base.send(:include, self::Configurable) + subclasses << base + end + end +</ruby> + +This +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: + +<ruby> + Rails.application = base.instance +</ruby> + +As 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: + +<ruby> + def instance + if self == Rails::Application + Rails.application + else + @@instance ||= new + end + end +</ruby> + +The +new+ method here simply creates a new +Rails::Application+ and sets it to the +@@instance+ class variable. No magic. + +h3. Your Application's Configuration + +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: + +<ruby> + def config + @config ||= Railtie::Configuration.new + end +</ruby> + +All the methods for +Rails::Railtie::Configuration+ are defined like this in _railties/lib/rails/railtie/configuration.rb_: + +<ruby> + require 'rails/configuration' + + module Rails + class Railtie + class Configuration + include Rails::Configuration::Shared + end + end + end +</ruby> + +As you can probably guess here, the +Rails::Configuration+ module is defined by _rails/configuration_ (_railties/lib/rails/configuration.rb_). + +h3. +Rails::Configuration::Shared+ + +In a standard application, the +application.rb+ looks like this with all the comments stripped out: + +<ruby> + require File.expand_path('../boot', __FILE__) + + module YourApp + class Application < Rails::Application + config.filter_parameters << :password + end + end +</ruby> + +The +config+ method being the one defined on +Rails::Application::Configurable+: + +<ruby> + def config + @config ||= Application::Configuration.new(self.class.find_root_with_flag("config.ru", Dir.pwd)) + end +</ruby> + +The 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: + +<ruby> + 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 + end +</ruby> + ++called_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: + +<pre> + /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>' +</pre> + ++called_from+ is defined in the +inherited+ method for +Rails::Engine+ which looks like this: + +<ruby> + 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 +</ruby> + +The +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.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 +/+. + +<ruby> + 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> + +TODO: 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: + +<ruby> + 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 + end +</ruby> + +The +super+ method here is the +initialize+ method in +Rails::Engine::Configuration+: + +<ruby> + def initialize(root=nil) + @root = root + end +</ruby> + +Here, 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: + +<ruby> + def method_missing(name, *args, &blk) + if name.to_s =~ config_key_regexp + return $2 == '=' ? options[$1] = args.first : options[$1] + end + super + end +</ruby> + +We'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: + +<ruby> + def options + @@options ||= Hash.new { |h,k| h[k] = ActiveSupport::OrderedOptions.new } + end +</ruby> + +OrderedOptions 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. + +h3. Application Configured! + +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!+. + +h3. Initialization begins + +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: + +<ruby> + def method_missing(*args, &block) + instance.send(*args, &block) + end +</ruby> + +With 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: + +<ruby> + def initialize! + run_initializers(self) + self + end +</ruby> + +The initializers it is talking about running here are the initializers for our application. The object passed in to +run_initializers+ is +YourApp::Application+. + + +h3. +run_initializers+ + +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: + +<ruby> + def run_initializers(*args) + return if instance_variable_defined?(:@ran) + initializers.each do |initializer| + initializer.run(*args) + end + @ran = true + end +</ruby> + +Here the +initializers+ method is defined in _railties/lib/rails/application.rb_: + +<ruby> + def initializers + initializers = Bootstrap.initializers_for(self) + railties.all { |r| initializers += r.initializers } + initializers += super + initializers += Finisher.initializers_for(self) + initializers + end +</ruby> + +h3. +Bootstrap+ initializers + +The 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+: + +<ruby> + autoload :Bootstrap, 'rails/application/bootstrap' +</ruby> + +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 +* bootstrap_load_path + +These are all defined using the +initializer+ method: + +<ruby> + 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) + end +</ruby> + +The +initializers+ method defined here just references an +@initializers+ variable: + +<ruby> + def initializers + @initializers ||= [] + end +</ruby> + +As 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: + +<ruby> + 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 + end +</ruby> + +Now that +Rails::Application::Bootstrap+ has finished loading, we can continue on with our initialization. We saw that it called this: + +<ruby> + initializers = Bootstrap.initializers_for(self) +</ruby> + +Calling +initializers_for+, defined like this: + +<ruby> + def initializers_for(binding) + Collection.new(initializers_chain.map { |i| i.bind(binding) }) + end +</ruby> + +The +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: + +<ruby> + def initializers_chain + initializers = Collection.new + ancestors.reverse_each do |klass| + next unless klass.respond_to?(:initializers) + initializers = initializers + klass.initializers + end + initializers + end +</ruby> + +The 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. + +<ruby> + def initializers_for(binding) + Collection.new(initializers_chain.map { |i| i.bind(binding) }) + end +</ruby> + +Wow. All that to cover just the first line in the +initializers+ method for +Rails::Application+. + +h3. Railties Initializers + +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+: + +<ruby> + def initializers + railties.all { |r| initializers += r.initializers } + end +</ruby> + +calls +railties+, which is defined like this: + +<ruby> + def railties + @railties ||= Railties.new(config) + end +</ruby> + +This sets up a new +Rails::Application::Railties+ object like this: + +<ruby> + def initialize(config) + @config = config + end +</ruby> + +And calls +all+ on it: + +<ruby> + def all(&block) + @all ||= railties + engines + plugins + @all.each(&block) if block + @all + end +</ruby> + +This +all+ method executes code on all the +Rails::Railtie+ and +Rails::Engine+ subclasses, retreived by the +railties+ and +engines+ methods defined right after +all+: + +<ruby> + def railties + @railties ||= ::Rails::Railtie.subclasses.map(&:new) + end + + def engines + @engines ||= ::Rails::Engine.subclasses.map(&:new) + end +</ruby> + +By 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: + +<ruby> + def plugins + @plugins ||= begin + plugin_names = (@config.plugins || [:all]).map { |p| p.to_sym } + Plugin.all(plugin_names, @config.paths.vendor.plugins) + end + end +</ruby> + ++@config.paths+ is defined in the +Rails::Application::Configuration+ like this: + +<ruby> + 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 + end +</ruby> + +When 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: + +<ruby> + config.plugins = [:will_paginate, :by_star] +</ruby> + +or specific plugin loading using a similar statement such as this next one: + +<ruby> + config.plugins = [:will_paginate, :by_star, :all] +</ruby> + + +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_): + +<ruby> + 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 + end +</ruby> + +As 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: + +<ruby> + def initialize(root) + @name = File.basename(root).to_sym + config.root = root + end +</ruby> + +This sets the plugin name to be the same name as the folder so the plugin located at _vendor/plugins/by\_star_'s name is +by_star+. After that, the +config+ object is initialized: + +<ruby> + def config + @config ||= Engine::Configuration.new + end +</ruby> + +and 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: + +<ruby> + 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) + end +</ruby> + +A 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: + +<ruby> + plugins.sort_by do |p| + [list.index(p.name) || list.index(:all), p.name.to_s] + end +</ruby> + +The 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: + +<ruby> + def initializers + railties.all { |r| initializers += r.initializers } + end +</ruby> + +This block will gather add the railties' initializers to it. + +h3. Engine Initializers + +The third line in this +initializers+ method: + +<ruby> + initializers += super +</ruby> + +The +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+. + +h3. Finisher Initializers + +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_. + +h3. Running the Initializers + +Now that we have all the initializers we can go back to the +run_initializers+ in +Rails::Initializable+: + +<ruby> + def run_initializers(*args) + return if instance_variable_defined?(:@ran) + initializers.each do |initializer| + initializer.run(*args) + end + @ran = true + end +</ruby> + +Now we finally have all the +initializers+ we can go through them and call +run+: + +<ruby> + def run(*args) + @context.instance_exec(*args, &block) + end +</ruby> + +You 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. + +h3. Bootstrap Initializers + +These initializers are the very first initializers that will be used to get your application going. + +h4. +load_environment_config+ + +<ruby> + initializer :load_environment_config do + require_environment! + end +</ruby> + +This quite simply makes a call to +require_environment!+ which is defined like this in +Rails::Application+: + +<ruby> + def require_environment! + environment = config.paths.config.environment.to_a.first + require environment if environment + end +</ruby> + +We'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: + +<ruby> + paths.config.environment "config/environments", :glob => "#{Rails.env}.rb" +</ruby> + ++Rails.env+ was defined way back in the boot process when +railties/lib/rails.rb+ was required: + +<ruby> +module Rails + class << self + + ... + + def env + @_env ||= ActiveSupport::StringInquirer.new(ENV["RAILS_ENV"] || ENV["RACK_ENV"] || "development") + end + + ... + + end +end +</ruby> + +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: + +<ruby> + paths.config.environment "config/environments", :glob => "development.rb" +</ruby> + +This method returns a +Path+ object (which acts as an +Enumerable+). + +Back to +require_environment+ now: + +<ruby> + def require_environment! + environment = config.paths.config.environment.to_a.first + require environment if environment + end +</ruby> + +And 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: + +<ruby> + alias to_a paths +</ruby> + +<ruby> + 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 + end +</ruby> + +This returns an array of files according to our +path+ and +@glob+ which are +config/environments+ and +development.rb+ respectively, therefore we can determine that: + +<ruby> + Dir[File.join(path, @glob)] +</ruby> + +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: + +<ruby> + 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 +</ruby> + +This +configure+ method is an +alias+ of +class_eval+ on +Rails::Application+: + +<ruby> + alias :configure :class_eval +</ruby> + +therefore, 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+: + +<ruby> + def method_missing(name, *args, &blk) + if name.to_s =~ config_key_regexp + return $2 == '=' ? options[$1] = args.first : options[$1] + end + super + end +</ruby> + +This 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: + +<ruby> + def config_key_regexp + bits = config_keys.map { |n| Regexp.escape(n.to_s) }.join('|') + /^(#{bits})(?:=)?$/ + end +</ruby> + +And also +config_keys+: + +<ruby> + def config_keys + (Railtie.railtie_names + Engine.engine_names).map { |n| n.to_s }.uniq + end +</ruby> + ++config_keys+ in here returns: + +<ruby> + [:active_support, :i18n, :action_dispatch, :action_view, :action_controller, :active_record, :action_mailer, :active_resource, :test_unit] +</ruby> + +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: + +<ruby> + def options + @@options ||= Hash.new { |h,k| h[k] = ActiveSupport::OrderedOptions.new } + end +</ruby> + +The values for these framework keys are +ActiveSupport::OrderedOptions+ objects, with the class defined like this: + +<ruby> + 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 + end +</ruby> + +We 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_. + +h4. +load_all_active_support+ + +This initializer does exactly what it says: + +<ruby> + initializer :load_all_active_support do + require "active_support/all" unless config.active_support.bare + end +</ruby> + +If 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. + +h4. +preload_frameworks+ + +Remember earlier how we had all that stuff +eager_autoload+'d for ActiveSupport? + +<ruby> + initializer :preload_frameworks do + require 'active_support/dependencies' + ActiveSupport::Autoload.eager_autoload! if config.preload_frameworks + end +</ruby> + +This is where it gets loaded. The +eager_autoload!+ method is defined like this: + +<ruby> + def self.eager_autoload! + @@autoloads.values.each { |file| require file } + end +</ruby> + +With +@@autoloads+ being + + +* load_all_active_support +* preload_frameworks +* initialize_logger +* initialize_cache +* initialize_subscriber +* set_clear_dependencies_hook +* initialize_dependency_mechanism +* bootstrap_load_path + +h4. ActiveSupport Initializers + +ActiveSupport + +**ActiveSupport 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. + +**ActionDispatch Initializers** + +* action_dispatch.prepare_dispatcher + +**ActionController Initializers** + +* action_controller.logger +* action_controller.set_configs +* action_controller.initialize_framework_caches +* action_controller.set_helpers_path + +**ActiveRecord 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 + +**ActionView Initializers ** + +* action_view.cache_asset_timestamps + +**ActionMailer Initializers ** + +* action_mailer.logger +* action_mailer.set_configs +* action_mailer.url_for + +**ActiveResource Initializers** + +* active_resource.set_configs + +**Rails::Engine Initializers** + +* set_load_path +* set_autoload_paths +* add_routing_paths + + +h4. +Rails::Engine.new+ + +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: + +<ruby> + def initialize + require_environment + Rails.application ||= self + @route_configuration_files = [] + end +</ruby> + +h4. +Rails::Application#require_environment+ + +This is not a crafty method like the previous ones, it just does as it says on the box: + +<ruby> + def require_environment + require config.environment_path + rescue LoadError + end +</ruby> + +The +config+ object here is actually another +delegate+'d method (along with +routes+), this time to +self.class+: + +<ruby> + delegate :config, :routes, :to => :'self.class' +</ruby> + +So the method call is actually +self.class.config+. + + +h4. +Rails::Application.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+: + +<ruby> + def config + @config ||= Configuration.new(Plugin::Configuration.default) + end +</ruby> + +h4. +Rails::Plugin::Configuration.default+ + +The +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: + +<ruby> + module Rails + class Plugin < Railtie + ... + end + end +</ruby> + +So 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! + +h4. +Rails::Railtie::Configuration+ + +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_: + +<ruby> + class Railtie::Configuration + def self.default + @default ||= new + end + ... + end +</ruby> + +In this case we have effectively seen that it's doing Configuration.new(Configuration.new). I'll explain why. + +h4. +Rails::Application::Configuration.new+ + +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: + +<ruby> + 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 + end +</ruby> + +This 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. + +h4. +default_middleware_stack+ + +This method is defined like this: + +<ruby> + 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 + end +</ruby> + +To 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. + +h4. +ActionDispatch::MiddlewareStack.new+ + ++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: + +<ruby> + module ActionDispatch + class MiddlewareStack < Array + + ... + + def initialize(*args, &block) + super(*args) + block.call(self) if block_given? + end + end + end +</ruby> + +When 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! + +h4. +ActionDispatch::MiddlewareStack.use+ + +Previously we saw a chunk of code that I'll re-show you stripped down: + +<ruby> + 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 + end +</ruby> + +As 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: + +<ruby> + def use(*args, &block) + middleware = Middleware.new(*args, &block) + push(middleware) + end +</ruby> + +We'll come back to this method later on. + +h4. +ActionController::Middleware.new+ + +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: + +<ruby> + module ActionController + class Middleware < Metal + + ... + + def initialize(app) + super() + @_app = app + end + end + end +</ruby> + +Here 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+. + +h4. +ActionController::Metal.initialize+ + +This is another subclassed class, this time from +ActionController::AbstractController+ and I'm sure you can guess what that means: + +<ruby> + class Metal < AbstractController::Base + + ... + + def initialize(*) + @_headers = {} + super + end + end +</ruby> + +The single +*+ in the argument listing means we can accept any number of arguments, we just don't care what they are. + +h4. +AbstractController::Base.initialize+ + +This may be anti-climatic, but the initialize method here just returns an +AbstractController::Base+ object: + +<ruby> + # Initialize controller with nil formats. + def initialize #:nodoc: + @_formats = nil + end +</ruby> + +h4. +ActionDispatch::MiddlewareStack.use+ + +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. + +h4. Back to +Rails::Application::Configuration.new+ + +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: + +<ruby> + 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 + end +</ruby> + +You'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: + +<ruby> + 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_path +</ruby> + +Along with these are a lot of helper methods, and one of them is +environment_path+: + +<ruby> + def environment_path + "#{root}/config/environments/#{Rails.env}.rb" + end +</ruby> + +h4. Back to +Rails::Application#require_environment+ + +Now 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. + +h4. _config/environments/development.rb_ + +In a standard Rails application we have this in our _config/environments/development.rb_ file: + +<ruby> + 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 +</ruby> + +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. + +h5. config.cache_classes= + +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. + +h5. config.whiny_nils= + +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: + +<ruby> + Called id for nil, which would mistakenly be 4 -- if you really wanted the id of nil, use object_id +</ruby> + +Or perhaps this one? + +<ruby> + 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! +</ruby> + +If you have, then this is _activesupport/whiny_nil_ at work. + + +h5. The frameworks + +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: + +<ruby> + def method_missing(name, *args, &blk) + if name.to_s =~ config_key_regexp + return $2 == '=' ? @options[$1] = args.first : @options[$1] + end + + super + end +</ruby> + +Whilst 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: + +<ruby> + def config_key_regexp + bits = config_keys.map { |n| Regexp.escape(n.to_s) }.join('|') + /^(#{bits})(?:=)?$/ + end +</ruby> + +As is +config_keys+: + +<ruby> + def config_keys + ([ :active_support, :action_view ] + + Railtie.plugin_names).map { |n| n.to_s }.uniq + end +</ruby> + +Aha! There we've got mention of +action_view+, but what is in +Railtie.plugin_names+? Most likely in this case the other frameworks. + +h5. +Railtie.plugin_names+ + +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: + +<ruby> + 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 + end +</ruby> + +In 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+. + +h3. Serving a Request + +Now that your application is fully initialized, it's now ready to start serving requests. + +h4. _rails server_ + +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: + +<ruby> + 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 + end +</ruby> + +We 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: + +<ruby> + def server + @_server ||= Rack::Handler.get(options[:server]) || Rack::Handler.default + end +</ruby> + +Our +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: + +<ruby> + def self.default(options = {}) + # Guess. + if ENV.include?("PHP_FCGI_CHILDREN") + # We already speak FastCGI + options.delete :File + options.delete :Port + + Rack::Handler::FastCGI + elsif ENV.include?("REQUEST_METHOD") + Rack::Handler::CGI + else + begin + Rack::Handler::Mongrel + rescue LoadError => e + Rack::Handler::WEBrick + end + end + end +</ruby> + + +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?) + +h5. +Rack::Handler::WEBrick+ + +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 + +h3. Cruft! + +The final line of _config/environment.rb_: + +<ruby> + YourApp::Application.initialize! +</ruby> + +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. + +<ruby> + 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 + end +</ruby> + +Because 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: + +<ruby> + def server + @_server ||= Rack::Handler.get(options[:server]) || Rack::Handler.default + end +</ruby> + +Since we have default options, the server is obviously going to be +Rack::Handler.default+. The +default+ method goes like this: + +<ruby> + def self.default(options = {}) + # Guess. + if ENV.include?("PHP_FCGI_CHILDREN") + # We already speak FastCGI + options.delete :File + options.delete :Port + + Rack::Handler::FastCGI + elsif ENV.include?("REQUEST_METHOD") + Rack::Handler::CGI + else + begin + Rack::Handler::Mongrel + rescue LoadError => e + Rack::Handler::WEBrick + end + end + end +</ruby> + +h3. +Rails::Paths+ + + +The +super+ method it references comes from +Rails::Engine::Configuration+ which defines these paths: + +<ruby> + 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 + end +</ruby> + +h3. Appendix A + +This 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: + +<ruby> +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 +</ruby> + +There's also these method definitions: + +<ruby> + 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 +</ruby> + +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 +force_encoding+ method. This method was introduced in Ruby 1.9. If you're using 1.9 the methods are defined like this: + +<ruby> + 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 + end +</ruby> + +You 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: + +<ruby> + 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 + + unless '1.8.7 and later'.respond_to?(:chars) + def chars + ActiveSupport::Deprecation.warn('String#chars has been deprecated in favor of String#mb_chars.', caller) + mb_chars + end + end + +</ruby> + + +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?+. + diff --git a/railties/guides/source/layout.html.erb b/railties/guides/source/layout.html.erb index a21f1bbeed..9819db1f89 100644 --- a/railties/guides/source/layout.html.erb +++ b/railties/guides/source/layout.html.erb @@ -1,3 +1,6 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> @@ -14,6 +17,11 @@ </head> <body class="guide"> + <% if @edge %> + <div> + <img src="images/edge_badge.png" alt="edge-badge" id="edge-badge" /> + </div> + <% end %> <div id="topNav"> <div class="wrapper"> <strong>More at <a href="http://rubyonrails.org/">rubyonrails.org:</a> </strong> @@ -101,7 +109,7 @@ <hr class="hide" /> <div id="footer"> <div class="wrapper"> - <p>This work is licensed under a <a href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-Share Alike 3.0</a> License</a></p> + <p>This work is licensed under a <a href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-Share Alike 3.0</a> License</p> <p>"Rails", "Ruby on Rails", and the Rails logo are trademarks of David Heinemeier Hansson. All rights reserved.</p> </div> </div> diff --git a/railties/guides/source/routing.textile b/railties/guides/source/routing.textile index 8cf084494b..6625412684 100644 --- a/railties/guides/source/routing.textile +++ b/railties/guides/source/routing.textile @@ -79,7 +79,7 @@ If you're coming from Rails 2, this route will be equivalent to: map.login '/login', :controller => 'sessions', :action => 'new' </ruby> -You will also notice that +sessions#new+ is a shorthand for +:controller => 'sessions', :action => 'new'+. By declaring a named route such as this, you can use +login_path+ or +login_url+ in your controllers and views to generate the URLs for this route. +You will also notice that +sessions#new+ is a shorthand for +:controller => 'sessions', :action => 'new'+. By declaring a named route such as this, you can use +login_path+ or +login_url+ in your controllers and views to generate the URLs for this route. A RESTful generates named routes without the need to explicitly generate a named route via +as+ key. h4. Nested Routes @@ -215,8 +215,7 @@ Although the conventions of RESTful routing are likely to be sufficient for many * +:controller+ * +:singular+ -* +:requirements+ -* +:conditions+ +* +:constraints+ * +:as+ * +:path_names+ * +:only+ @@ -257,13 +256,7 @@ If you use controller namespaces, you need to be aware of a subtlety in the Rail TIP: If you want to guarantee that a link goes to a top-level controller, use a preceding slash to anchor the controller name: +<%= link_to "show", {:controller => "/photos", :action => "show"} %>+ -You can also specify a controller namespace with the +:namespace+ option instead of a path: - -<ruby> -resources :adminphotos, :namespace => "admin", :controller => "photos" -</ruby> - -This can be especially useful when map multiple namespaced routes together using +namespace+ block by: +You can also specify a controller namespace with the +namespace+ method instead of a path. This can be especially useful when mapping multiple namespaced routes together: <ruby> namespace :admin do @@ -285,20 +278,16 @@ resources :teeth, :singular => "tooth" TIP: Depending on the other code in your application, you may prefer to add additional rules to the +Inflector+ class instead. -h5. Using +:requirements+ +h5. Using +:constraints+ -You can use the +:requirements+ option in a RESTful route to impose a format on the implied +:id+ parameter in the singular routes. For example: +You can use the +:constraints+ option in a RESTful route to impose a format on the implied parameter in routes. For example: <ruby> -resources :photos, :requirements => {:id => /[A-Z][A-Z][0-9]+/} +resources :photos, :constraints => {:id => /[A-Z][A-Z][0-9]+/} </ruby> This declaration constrains the +:id+ parameter to match the supplied regular expression. So, in this case, +/photos/1+ would no longer be recognized by this route, but +/photos/RR27+ would. -h5. Using +:conditions+ - -Conditions in Rails routing are currently used only to set the HTTP verb for individual routes. Although in theory you can set this for RESTful routes, in practice there is no good reason to do so. (You'll learn more about conditions in the discussion of classic routing later in this guide.) - h5. Using +:as+ The +:as+ option lets you override the normal naming for the actual generated paths. For example: @@ -343,37 +332,15 @@ TIP: If you find yourself wanting to change this option uniformly for all of you config.action_controller.resources_path_names = { :new => 'make', :edit => 'change' } </ruby> -h5. Using +:path_prefix+ - -The +:path_prefix+ option lets you add additional parameters that will be prefixed to the recognized paths. For example, suppose each photo in your application belongs to a particular photographer. In that case, you might declare this route: - -<ruby> -resources :photos, :path_prefix => '/photographers/:photographer_id' -</ruby> - -Routes recognized by this entry would include: - -<pre> -/photographers/1/photos/2 -/photographers/1/photos -</pre> - -NOTE: In most cases, it's simpler to recognize URLs of this sort by creating nested resources, as discussed in the next section. - -NOTE: You can also use +:path_prefix+ with non-RESTful routes. - h5. Using +:name_prefix+ You can use the :name_prefix option to avoid collisions between routes. This is most useful when you have two resources with the same name that use +:path_prefix+ to map differently. For example: <ruby> -resources :photos, :path_prefix => '/photographers/:photographer_id', - :name_prefix => 'photographer_' -resources :photos, :path_prefix => '/agencies/:agency_id', - :name_prefix => 'agency_' +resources :photos :name_prefix => 'photographer' </ruby> -This combination will give you route helpers such as +photographer_photos_path+ and +agency_edit_photo_path+ to use in your code. +This combination will give you route helpers such as +photographer_photos_path+ to use in your code. NOTE: You can also use +:name_prefix+ with non-RESTful routes. @@ -395,8 +362,6 @@ resources :photos, :except => :destroy In this case, all of the normal routes except the route for +destroy+ (a +DELETE+ request to +/photos/<em>id</em>+) will be generated. -In addition to an action or a list of actions, you can also supply the special symbols +:all+ or +:none+ to the +:only+ and +:except+ options. - TIP: If your application has many RESTful routes, using +:only+ and +:except+ to generate only the routes that you actually need can cut down on memory use and speed up the routing process. h4. Nested Resources @@ -421,8 +386,6 @@ resources :magazines do end </ruby> -TIP: Further below you'll learn about a convenient shortcut for this construct:<br/>+resources :magazines, :has_many => :ads+ - In addition to the routes for magazines, this declaration will also create routes for ads, each of which requires the specification of a magazine in the URL: |_.HTTP verb|_.URL |_.controller|_.action |_.used for| @@ -447,38 +410,7 @@ resources :magazines do end </ruby> -This will create routing helpers such as +periodical_ads_url+ and +periodical_edit_ad_path+. You can even use +:name_prefix+ to suppress the prefix entirely: - -<ruby> -resources :magazines do - resources :ads, :name_prefix => nil -end -</ruby> - -This will create routing helpers such as +ads_url+ and +edit_ad_path+. Note that calling these will still require supplying an article id: - -<ruby> -ads_url(@magazine) -edit_ad_path(@magazine, @ad) -</ruby> - -h5. Using +:has_one+ and +:has_many+ - -The +:has_one+ and +:has_many+ options provide a succinct notation for simple nested routes. Use +:has_one+ to nest a singleton resource, or +:has_many+ to nest a plural resource: - -<ruby> -resources :photos, :has_one => :photographer, :has_many => [:publications, :versions] -</ruby> - -This has the same effect as this set of declarations: - -<ruby> -resources :photos do - resource :photographer - resources :publications - resources :versions -end -</ruby> +This will create routing helpers such as +periodical_ads_url+ and +periodical_edit_ad_path+. h5. Limits to Nesting @@ -492,7 +424,7 @@ resources :publishers do end </ruby> -However, without the use of +name_prefix => nil+, deeply-nested resources quickly become cumbersome. In this case, for example, the application would recognize URLs such as +Deeply-nested resources quickly become cumbersome. In this case, for example, the application would recognize URLs such as <pre> /publishers/1/magazines/2/photos/3 @@ -524,11 +456,7 @@ This will enable recognition of (among others) these routes: /photos/3 ==> photo_path(3) </pre> -With shallow nesting, you need only supply enough information to uniquely identify the resource that you want to work with. If you like, you can combine shallow nesting with the +:has_one+ and +:has_many+ options: - -<ruby> -resources :publishers, :has_many => { :magazines => :photos }, :shallow => true -</ruby> +With shallow nesting, you need only supply enough information to uniquely identify the resource that you want to work with. h4. Route Generation from Arrays @@ -556,19 +484,25 @@ This format is especially useful when you might not know until runtime which of h4. Namespaced Resources -It's possible to do some quite complex things by combining +:path_prefix+ and +:name_prefix+. For example, you can use the combination of these two options to move administrative resources to their own folder in your application: +It's possible to do some quite complex things by combining +scope+ and +:name_prefix+. For example, you can use the combination of these two options to move administrative resources to their own folder in your application: <ruby> -resources :photos, :path_prefix => 'admin', :controller => 'admin/photos' -resources :tags, :name_prefix => 'admin_photo_', :path_prefix => 'admin/photos/:photo_id', :controller => 'admin/photo_tags' -resources :ratings, :name_prefix => 'admin_photo_', :path_prefix => 'admin/photos/:photo_id', :controller => 'admin/photo_ratings' +scope 'admin' do + resources :photos, :name_prefix => "admin", :controller => 'admin/photos' + scope 'photos' do + resources :tags, :name_prefix => 'admin_photo', :controller => 'admin/photo_tags' + resources :ratings, :name_prefix => 'admin_photo', :controller => 'admin/photo_ratings' + end +end </ruby> The good news is that if you find yourself using this level of complexity, you can stop. Rails supports _namespaced resources_ to make placing resources in their own folder a snap. Here's the namespaced version of those same three routes: <ruby> namespace :admin do - resources :photos, :has_many => { :tags, :ratings } + resources :photos do + resources :tags, :ratings + end end </ruby> @@ -592,7 +526,7 @@ end This will enable Rails to recognize URLs such as +/photos/1/preview+ using the GET HTTP verb, and route them to the preview action of the Photos controller. It will also create the +preview_photo_url+ and +preview_photo_path+ route helpers. -Within the block of member routes, each route name specifies the HTTP verb that it will recognize. You can use +get+, +put+, +post+, +delete+, or +any+ here. If you don't have multiple +member+ route, you can also passing +:on+ to the routing. +Within the block of member routes, each route name specifies the HTTP verb that it will recognize. You can use +get+, +put+, +post+, or +delete+ here. If you don't have multiple +member+ route, you can also passing +:on+ to the routing. <ruby> resources :photos do @@ -649,7 +583,7 @@ When you set up a regular route, you supply a series of symbols that Rails maps match ':controller(/:action(/:id))' </ruby> -If an incoming request of +/photos/show/1+ is processed by this route (because it hasn't matched any previous route in the file), then the result will be to invoke the +show+ action of the +Photos+ controller, and to make the final parameter (1) available as +params[:id]+. +If an incoming request of +/photos/show/1+ is processed by this route (because it hasn't matched any previous route in the file), then the result will be to invoke the +show+ action of the +Photos+ controller, and to make the final parameter (1) available as +params[:id]+. This route will also route the incoming request of +/photos+ to PhotosController, since +:action+ and +:id+ are optional parameters, denoted by parenthesis. h4. Wildcard Components @@ -709,12 +643,12 @@ match 'logout' => 'sessions#destroy', :as => :logout This will do two things. First, requests to +/logout+ will be sent to the +destroy+ action of the +Sessions+ controller. Second, Rails will maintain the +logout_path+ and +logout_url+ helpers for use within your code. -h4. Route Requirements +h4. Route Constraints -You can use the +:requirements+ option to enforce a format for any parameter in a route: +You can use the +:constraints+ option to enforce a format for any parameter in a route: <ruby> -match 'photo/:id' => 'photos#show', :requirements => { :id => /[A-Z]\d{5}/ } +match 'photo/:id' => 'photos#show', :constraints => { :id => /[A-Z]\d{5}/ } </ruby> This route would respond to URLs such as +/photo/A12345+. You can more succinctly express the same route this way: @@ -723,16 +657,6 @@ This route would respond to URLs such as +/photo/A12345+. You can more succinctl match 'photo/:id' => 'photos#show', :id => /[A-Z]\d{5}/ </ruby> -h4. Route Conditions - -Route conditions (introduced with the +:conditions+ option) are designed to implement restrictions on routes. Currently, the only supported restriction is +:method+: - -<ruby> -match 'photo/:id' => 'photos#show', :conditions => { :method => :get } -</ruby> - -As with conditions in RESTful routes, you can specify +:get+, +:post+, +:put+, +:delete+, or +:any+ for the acceptable method. - h4. Route Globbing Route globbing is a way to specify that a particular parameter should be matched to all the remaining parts of a route. For example @@ -743,20 +667,6 @@ match 'photo/*other' => 'photos#unknown' This route would match +photo/12+ or +/photo/long/path/to/12+ equally well, creating an array of path segments as the value of +params[:other]+. -h4. Route Options - -You can use +:with_options+ to simplify defining groups of similar routes: - -<ruby> -map.with_options :controller => 'photo' do |photo| - photo.list '', :action => 'index' - photo.delete ':id/delete', :action => 'delete' - photo.edit ':id/edit', :action => 'edit' -end -</ruby> - -The importance of +map.with_options+ has declined with the introduction of RESTful routes. - h3. Formats and +respond_to+ There's one more way in which routing can do different things depending on differences in the incoming HTTP request: by issuing a response that corresponds to what the request specifies that it will accept. In Rails routing, you can control this with the special +:format+ parameter in the route. @@ -899,6 +809,7 @@ h3. Changelog "Lighthouse ticket":http://rails.lighthouseapp.com/projects/16213-rails-guides/tickets/3 +* April 2, 2010: Updated guide to match new Routing DSL in Rails 3, by Rizwan Reza * Febuary 1, 2010: Modifies the routing documentation to match new routing DSL in Rails 3, by Prem Sichanugrist * October 4, 2008: Added additional detail on specifying verbs for resource member/collection routes, by "Mike Gunderloy":credits.html#mgunderloy * September 23, 2008: Added section on namespaced controllers and routing, by "Mike Gunderloy":credits.html#mgunderloy diff --git a/railties/lib/rails/generators/migration.rb b/railties/lib/rails/generators/migration.rb index 7975326c52..9244307261 100644 --- a/railties/lib/rails/generators/migration.rb +++ b/railties/lib/rails/generators/migration.rb @@ -2,7 +2,7 @@ module Rails module Generators # Holds common methods for migrations. It assumes that migrations has the # [0-9]*_name format and can be used by another frameworks (like Sequel) - # just by implementing the next migration number method. + # just by implementing the next migration version method. # module Migration attr_reader :migration_number, :migration_file_name, :migration_class_name @@ -32,10 +32,10 @@ module Rails end # Creates a migration template at the given destination. The difference - # to the default template method is that the migration number is appended + # to the default template method is that the migration version is appended # to the destination file name. # - # The migration number, migration file name, migration class name are + # The migration version, migration file name, migration class name are # available as instance variables in the template to be rendered. # # ==== Examples |