diff options
Diffstat (limited to 'guides/source')
| -rw-r--r-- | guides/source/active_support_core_extensions.textile | 7 | ||||
| -rw-r--r-- | guides/source/contributing_to_ruby_on_rails.textile | 29 | ||||
| -rw-r--r-- | guides/source/getting_started.textile | 42 | ||||
| -rw-r--r-- | guides/source/rails_on_rack.textile | 62 |
4 files changed, 113 insertions, 27 deletions
diff --git a/guides/source/active_support_core_extensions.textile b/guides/source/active_support_core_extensions.textile index e2118e8f61..587f65529e 100644 --- a/guides/source/active_support_core_extensions.textile +++ b/guides/source/active_support_core_extensions.textile @@ -2579,6 +2579,13 @@ end There's also the bang variant +transform_keys!+ that applies the block operations to keys in the very receiver. +Besides that, one can use +deep_transform_keys+ and +deep_transform_keys!+ to perform the block operation on all the keys in the given hash and all the hashes nested into it. An example of the result is: + +<ruby> +{nil => nil, 1 => 1, :nested => {:a => 3, 5 => 5}}.deep_transform_keys{ |key| key.to_s.upcase } +# => {""=>nil, "1"=>1, "NESTED"=>{"A"=>3, "5"=>5}} +</ruby> + NOTE: Defined in +active_support/core_ext/hash/keys.rb+. h5. +stringify_keys+ and +stringify_keys!+ diff --git a/guides/source/contributing_to_ruby_on_rails.textile b/guides/source/contributing_to_ruby_on_rails.textile index a2254a550c..72cdea885f 100644 --- a/guides/source/contributing_to_ruby_on_rails.textile +++ b/guides/source/contributing_to_ruby_on_rails.textile @@ -430,6 +430,35 @@ h4. Iterate as Necessary It’s entirely possible that the feedback you get will suggest changes. Don’t get discouraged: the whole point of contributing to an active open source project is to tap into community knowledge. If people are encouraging you to tweak your code, then it’s worth making the tweaks and resubmitting. If the feedback is that your code doesn’t belong in the core, you might still think about releasing it as a gem. +h4. Backporting + +Changes that are merged into master are intended for the next major release of Rails. Sometimes, it might be beneficial for your changes to propagate back to the maintenance releases for older stable branches. Generally, security fixes and bug fixes are good candidates for a backport, while new features and patches that introduce a change in behavior will not be accepted. When in doubt, it is best to consult a rails team member before backporting your changes to avoid wasted effort. + +For simple fixes, the easiest way to backport your change is to "extract a diff from your changes in master and apply them to the target branch":http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git. + +First make sure your changes are the only difference between your current branch and master: + +<shell> +$ git log master..HEAD +</shell> + +Then extract the diff: + +<shell> +$ git format-patch master --stdout > ~/my_changes.patch +</shell> + +Switch over to the target branch and apply your changes: + +<shell> +$ git checkout -b my_backport_branch 3-2-stable +$ git apply ~/my_changes.patch +</shell> + +This works well for simple changes. However, if your changes are complicated or if the code in master has deviated significantly from your target branch, it might require more work on your part. The difficulty of a backport varies greatly from case to case, and sometimes it is simply not worth the effort. + +Once you have resolved all conflicts and made sure all the tests are passing, push your changes and open a separate pull request for your backport. It is also worth noting that older branches might have a different set of build targets than master. When possible, it is best to first test your backport locally against the ruby versions listed in +.travis.yml+ before submitting your pull request. + And then ... think about your next contribution! h3. Rails Contributors diff --git a/guides/source/getting_started.textile b/guides/source/getting_started.textile index 342e7284b0..f25e0c0200 100644 --- a/guides/source/getting_started.textile +++ b/guides/source/getting_started.textile @@ -177,7 +177,28 @@ To create a new controller, you will need to run the "controller" generator and $ rails generate controller welcome index </shell> -Rails will create several files for you. Most important of these are of course the controller, located at +app/controllers/welcome_controller.rb+ and the view, located at +app/views/welcome/index.html.erb+. +Rails will create several files and a route for you. + +<shell> +create app/controllers/welcome_controller.rb + route get "welcome/index" +invoke erb +create app/views/welcome +create app/views/welcome/index.html.erb +invoke test_unit +create test/functional/welcome_controller_test.rb +invoke helper +create app/helpers/welcome_helper.rb +invoke test_unit +create test/unit/helpers/welcome_helper_test.rb +invoke assets +invoke coffee +create app/assets/javascripts/welcome.js.coffee +invoke scss +create app/assets/stylesheets/welcome.css.scss +</shell> + +Most important of these are of course the controller, located at +app/controllers/welcome_controller.rb+ and the view, located at +app/views/welcome/index.html.erb+. Open the +app/views/welcome/index.html.erb+ file in your text editor and edit it to contain a single line of code: @@ -195,18 +216,27 @@ You need to do this because Rails will serve any static file in the +public+ dir Next, you have to tell Rails where your actual home page is located. -Open the file +config/routes.rb+ in your editor. This is your application's _routing file_ which holds entries in a special DSL (domain-specific language) that tells Rails how to connect incoming requests to controllers and actions. This file contains many sample routes on commented lines, and one of them actually shows you how to connect the root of your site to a specific controller and action. Find the line beginning with +root :to+ and uncomment it. It should look something like the following: +Open the file +config/routes.rb+ in your editor. <ruby> Blog::Application.routes.draw do - - #... + get "welcome/index" + + # The priority is based upon order of creation: + # first created -> highest priority. + # ... # You can have the root of your site routed with "root" # just remember to delete public/index.html. - root :to => "welcome#index" + # root :to => "welcome#index" +</ruby> + +This is your application's _routing file_ which holds entries in a special DSL (domain-specific language) that tells Rails how to connect incoming requests to controllers and actions. This file contains many sample routes on commented lines, and one of them actually shows you how to connect the root of your site to a specific controller and action. Find the line beginning with +root :to+ and uncomment it. It should look something like the following: + +<ruby> +root :to => "welcome#index" </ruby> -The +root :to => "welcome#index"+ tells Rails to map requests to the root of the application to the welcome controller's index action. This was created earlier when you ran the controller generator (+rails generate controller welcome index+). +The +root :to => "welcome#index"+ tells Rails to map requests to the root of the application to the welcome controller's index action and +get "welcome/index"+ tells Rails to map requests to "http://localhost:3000/welcome/index":http://localhost:3000/welcome/index to the welcome controller's index action. This was created earlier when you ran the controller generator (+rails generate controller welcome index+). If you navigate to "http://localhost:3000":http://localhost:3000 in your browser, you'll see the +Hello, Rails!+ message you put into +app/views/welcome/index.html.erb+, indicating that this new route is indeed going to +WelcomeController+'s +index+ action and is rendering the view correctly. diff --git a/guides/source/rails_on_rack.textile b/guides/source/rails_on_rack.textile index d8910cf1d0..3a7c392508 100644 --- a/guides/source/rails_on_rack.textile +++ b/guides/source/rails_on_rack.textile @@ -23,29 +23,49 @@ h3. Rails on Rack h4. Rails Application's Rack Object -<tt>ActionController::Dispatcher.new</tt> is the primary Rack application object of a Rails application. Any Rack compliant web server should be using +ActionController::Dispatcher.new+ object to serve a Rails application. +<tt>ApplicationName::Application</tt> is the primary Rack application object of a Rails application. Any Rack compliant web server should be using +ApplicationName::Application+ object to serve a Rails application. h4. +rails server+ -<tt>rails server</tt> does the basic job of creating a +Rack::Builder+ object and starting the webserver. This is Rails' equivalent of Rack's +rackup+ script. +<tt>rails server</tt> does the basic job of creating a +Rack::Server+ object and starting the webserver. -Here's how +rails server+ creates an instance of +Rack::Builder+ +Here's how +rails server+ creates an instance of +Rack::Server+ <ruby> -app = Rack::Builder.new { - use Rails::Rack::LogTailer unless options[:detach] - use Rails::Rack::Debugger if options[:debugger] - use ActionDispatch::Static - run ActionController::Dispatcher.new -}.to_app +Rails::Server.new.tap { |server| + require APP_PATH + Dir.chdir(Rails.application.root) + server.start +} </ruby> -Middlewares used in the code above are primarily useful only in the development environment. The following table explains their usage: +The +Rails::Server+ inherits from +Rack::Server+ and calls the +Rack::Server#start+ method this way: + +<ruby> +class Server < ::Rack::Server + def start + ... + super + end +end +</ruby> + +Here's how it loads the middlewares: + +<ruby> +def middleware + middlewares = [] + middlewares << [Rails::Rack::Debugger] if options[:debugger] + middlewares << [::Rack::ContentLength] + Hash.new(middlewares) +end +</ruby> + ++Rails::Rack::Debugger+ is primarily useful only in the development environment. The following table explains the usage of the loaded middlewares: |_.Middleware|_.Purpose| -|+Rails::Rack::LogTailer+|Appends log file output to console| -|+ActionDispatch::Static+|Serves static files inside +Rails.root/public+ directory| |+Rails::Rack::Debugger+|Starts Debugger| +|+Rack::ContentLength+|Counts the number of bytes in the response and set the HTTP Content-Length header| h4. +rackup+ @@ -55,9 +75,9 @@ To use +rackup+ instead of Rails' +rails server+, you can put the following insi # Rails.root/config.ru require "config/environment" -use Rails::Rack::LogTailer -use ActionDispatch::Static -run ActionController::Dispatcher.new +use Rack::Debugger +use Rack::ContentLength +run ApplicationName::Application </ruby> And start the server: @@ -72,11 +92,11 @@ To find out more about different +rackup+ options: $ rackup --help </shell> -h3. Action Controller Middleware Stack +h3. Action Dispatcher Middleware Stack -Many of Action Controller's internal components are implemented as Rack middlewares. +ActionController::Dispatcher+ uses +ActionController::MiddlewareStack+ to combine various internal and external middlewares to form a complete Rails Rack application. +Many of Action Dispatchers's internal components are implemented as Rack middlewares. +Rails::Application+ uses +ActionDispatch::MiddlewareStack+ to combine various internal and external middlewares to form a complete Rails Rack application. -NOTE: +ActionController::MiddlewareStack+ is Rails' equivalent of +Rack::Builder+, but built for better flexibility and more features to meet Rails' requirements. +NOTE: +ActionDispatch::MiddlewareStack+ is Rails' equivalent of +Rack::Builder+, but built for better flexibility and more features to meet Rails' requirements. h4. Inspecting Middleware Stack @@ -111,7 +131,7 @@ use ActionDispatch::Head use Rack::ConditionalGet use Rack::ETag use ActionDispatch::BestStandardsSupport -run Blog::Application.routes +run ApplicationName::Application.routes </ruby> Purpose of each of this middlewares is explained in the "Internal Middlewares":#internal-middleware-stack section. @@ -172,7 +192,7 @@ use ActionDispatch::Static use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x00000001c304c8> use Rack::Runtime ... -run Myapp::Application.routes +run Blog::Application.routes </shell> h4. Internal Middleware Stack @@ -264,7 +284,7 @@ config.middleware.clear <ruby> # config.ru use MyOwnStackFromScratch -run ActionController::Dispatcher.new +run ApplicationName::Application </ruby> h3. Resources |