aboutsummaryrefslogtreecommitdiffstats
path: root/guides/source
diff options
context:
space:
mode:
authorVijay Dev <vijaydev.cse@gmail.com>2012-06-22 22:15:27 +0530
committerVijay Dev <vijaydev.cse@gmail.com>2012-06-22 22:15:27 +0530
commit35ee8fa3d8b3ad49179f86af2bec2e53af335ac9 (patch)
tree5929e772a461c683c54c1fd66b303516e5d0df33 /guides/source
parentfb8cf55868d555b7f06215db5976c8aaf083d30b (diff)
parent6285675db1cf983ba6c15442aedb457c8041f5ee (diff)
downloadrails-35ee8fa3d8b3ad49179f86af2bec2e53af335ac9.tar.gz
rails-35ee8fa3d8b3ad49179f86af2bec2e53af335ac9.tar.bz2
rails-35ee8fa3d8b3ad49179f86af2bec2e53af335ac9.zip
Merge branch 'master' of github.com:lifo/docrails
Diffstat (limited to 'guides/source')
-rw-r--r--guides/source/ajax_on_rails.textile120
-rw-r--r--guides/source/asset_pipeline.textile24
-rw-r--r--guides/source/contributing_to_ruby_on_rails.textile2
-rw-r--r--guides/source/initialization.textile33
4 files changed, 119 insertions, 60 deletions
diff --git a/guides/source/ajax_on_rails.textile b/guides/source/ajax_on_rails.textile
index bfd007490a..e23fdf9a74 100644
--- a/guides/source/ajax_on_rails.textile
+++ b/guides/source/ajax_on_rails.textile
@@ -1,6 +1,8 @@
h2. AJAX on Rails
-This guide covers the built-in Ajax/JavaScript functionality of Rails (and more); it will enable you to create rich and dynamic AJAX applications with ease! We will cover the following topics:
+This guide covers the built-in Ajax/JavaScript functionality of Rails (and more);
+it will enable you to create rich and dynamic AJAX applications with ease! We will
+cover the following topics:
* Quick introduction to AJAX and related technologies
* Unobtrusive JavaScript helpers with drivers for Prototype, jQuery etc
@@ -10,34 +12,99 @@ endprologue.
h3. Hello AJAX - a Quick Intro
-You'll need the basics of DOM, HTTP requests and other topics discussed here to really understand Ajax on Rails.
+AJAX is about updating parts of a web page without reloading the page. An AJAX
+call happens as a response to an event, like when the page finished loading or
+when a user clicks on an element. For example, let say you click on a link, which
+would usually take you to a new page, but instead of doing that, an asynchronous
+HTTP request is made and the response is evaluated with JavaScript. That way the
+page is not reloaded and new information can be dynamically included in the page.
+The way that happens is by inserting, removing or changing parts of the DOM. The
+DOM, or Document Object Model, is a convention to represent the HTML document as
+a set of nodes that contain other nodes. For example, a list of names is represented
+as a +ul+ element node containing several +li+ element nodes. An AJAX call can
+be made to obtain a new list item to include, and append it inside a +li+ node to
+the +ul+ node.
h4. Asynchronous JavaScript + XML
-Basic terminology, new style of creating web apps
+AJAX means Asynchronous JavaScript + XML. Asynchronous means that the page is not
+reloaded, the request made is separate from the regular page request. Javascript
+is used to evaluate the response and the XML part is a bit misleading as XML is
+not required, you respond to the HTTP request with JSON or regular HTML as well.
h4. The DOM
-basics of the DOM, how is it built, properties, features, why is it central to AJAX
+The DOM (Document Object Model) is a convention to represent HTML (or XML)
+documents, as a set of nodes that act as objects and contain other nodes. You can
+have a +div+ element that contains other +div+ elements as well as +p+ elements
+that contain text.
h4. Standard HTML communication vs AJAX
-How do 'standard' and AJAX requests differ, why does this matter for understanding AJAX on Rails (tie in for *_remote helpers, the next section)
+In regular HTML comunications, when you click on a link, the browser makes an HTTP
++GET+ request, the server responds with a new HTML document that the browsers renders
+and then replaces the previous one. The same thing happens when you click a button to
+submit a form, except that you make and HTTP +POST+ request, but you also get a new
+HTML document that the browser renders and replaces the current one. In AJAX
+communications, the request is separate, and the response is evaluated in JavaScript
+instead of rendered by the browser. That way you can have more control over the content
+that gets returned, and the page is not reloaded.
h3. Built-in Rails Helpers
-Rails 3.1 ships with "jQuery":http://jquery.com as the default JavaScript library. The Gemfile contains <tt>gem 'jquery-rails'</tt> which makes the jQuery files available to the application automatically. This can be accessed as:
+Rails 4.0 ships with "jQuery":http://jquery.com as the default JavaScript library.
+The Gemfile contains +gem 'jquery-rails'+ which provides the +jquery.js+ and
++jquery_ujs.js+ files via the asset pipeline.
+
+You will have to use the +require+ directive to tell Sprockets to load +jquery.js+
+and +jquery.js+. For example, a new Rails application includes a default
++app/assets/javascripts/application.js+ file which contains the following lines:
+
+<plain>
+// ...
+//= require jquery
+//= require jquery_ujs
+// ...
+</plain>
+
+The +application.js+ file acts like a manifest and is used to tell Sprockets the
+files that you wish to require. In this case, you are requiring the files +jquery.js+
+and +jquery_ujs.js+ provided by the +jquery-rails+ gem.
+
+If the application is not using the asset pipeline, this can be accessed as:
<ruby>
javascript_include_tag :defaults
</ruby>
+By default, +:defaults+ loads jQuery.
+
+You can also choose to use Prototype instead of jQuery and specify the option
+using +-j+ switch while generating the application.
+
+<shell>
+rails new app_name -j prototype
+</shell>
+
+This will add the +prototype-rails+ gem to the Gemfile and modify the
++app/assets/javascripts/application.js+ file:
+
+<plain>
+// ...
+//= require prototype
+//= require prototype_ujs
+// ...
+</plain>
+
+You are ready to add some AJAX love to your Rails app!
+
h4. Examples
-All the remote_method helpers has been removed. To make them working with AJAX, simply pass the <tt>:remote => true</tt> option to the original non-remote method.
+To make them working with AJAX, simply pass the <tt>remote: true</tt> option to
+the original non-remote method.
<ruby>
-button_to "New", :action => "new", :form_class => "new-thing"
+button_to 'New', action: 'new', form_class: 'new-thing'
</ruby>
will produce
@@ -49,7 +116,7 @@ will produce
</html>
<ruby>
-button_to "Create", :action => "create", :remote => true, :form => { "data-type" => "json" }
+button_to 'Create', action: 'create', remote: true, form: { 'data-type' => 'json' }
</ruby>
will produce
@@ -61,8 +128,8 @@ will produce
</html>
<ruby>
-button_to "Delete Image", { :action => "delete", :id => @image.id },
- :confirm => "Are you sure?", :method => :delete
+button_to 'Delete Image', { action: 'delete', id: @image.id },
+ confirm: 'Are you sure?', method: :delete
</ruby>
will produce
@@ -77,8 +144,8 @@ will produce
</html>
<ruby>
-button_to('Destroy', 'http://www.example.com', :confirm => 'Are you sure?',
- :method => "delete", :remote => true, 'data-disable-with' => 'loading...')
+button_to 'Destroy', 'http://www.example.com', confirm: 'Are you sure?',
+ method: 'delete', remote: true, data: { disable_with: 'loading...' }
</ruby>
will produce
@@ -92,14 +159,6 @@ will produce
</form>
</html>
-You can also choose to use Prototype instead of jQuery and specify the option using +-j+ switch while generating the application.
-
-<shell>
-rails new app_name -j prototype
-</shell>
-
-You are ready to add some AJAX love to your Rails app!
-
h4. The Quintessential AJAX Rails Helper: link_to_remote
Let's start with what is probably the most often used helper: +link_to_remote+. It has an interesting feature from the documentation point of view: the options supplied to +link_to_remote+ are shared by all other AJAX helpers, so learning the mechanics and options of +link_to_remote+ is a great help when using other helpers.
@@ -223,23 +282,6 @@ h5. +form_remote_tag+
h5. +submit_to_remote+
-h4. Observing Elements
-
-h5. +observe_field+
-
-h5. +observe_form+
-
-h4. Calling a Function Periodically
-
-h5. +periodically_call_remote+
-
-
-h4. Miscellaneous Functionality
-
-h5. +remote_function+
-
-h5. +update_page+
-
h4. Serving JavaScript
First we'll check out how to send JavaScript to the server manually. You are practically never going to need this, but it's interesting to understand what's going on under the hood.
@@ -265,4 +307,4 @@ JavaScript testing reminds me the definition of the world 'classic' by Mark Twai
* Cucumber+Webrat
* Mention stuff like screw.unit/jsSpec
-Note to self: check out the RailsConf JS testing video
+Note to self: check out the RailsConf JS testing video \ No newline at end of file
diff --git a/guides/source/asset_pipeline.textile b/guides/source/asset_pipeline.textile
index 105efe229e..d0952fcf29 100644
--- a/guides/source/asset_pipeline.textile
+++ b/guides/source/asset_pipeline.textile
@@ -649,11 +649,19 @@ Apache and nginx support this option, which can be enabled in <tt>config/environ
WARNING: If you are upgrading an existing application and intend to use this option, take care to paste this configuration option only into +production.rb+ and any other environments you define with production behavior (not +application.rb+).
-h3. How Caching Works
+h3. Assets Cache Store
-Sprockets uses the default Rails cache store to cache assets in development and production.
+Sprockets uses the default Rails cache store will be used to cache assets in development and production. This can be changed by setting +config.assets.cache_store+.
-TODO: Add more about changing the default store.
+<ruby>
+config.assets.cache_store = :memory_store
+</ruby>
+
+The options accepted by the assets cache store are the same as the application's cache store.
+
+<ruby>
+config.assets.cache_store = :memory_store, { :size => 32.megabytes }
+</ruby>
h3. Adding Assets to Your Gems
@@ -667,9 +675,11 @@ TODO: Registering gems on "Tilt":https://github.com/rtomayko/tilt enabling Sproc
h3. Upgrading from Old Versions of Rails
-There are two issues when upgrading. The first is moving the files from +public/+ to the new locations. See "Asset Organization":#asset-organization above for guidance on the correct locations for different file types.
+There are a few issues when upgrading. The first is moving the files from +public/+ to the new locations. See "Asset Organization":#asset-organization above for guidance on the correct locations for different file types.
+
+Next will be avoiding duplicate JavaScript files. Since jQuery is the default JavaScript library from Rails 3.1 onwards, you don't need to copy +jquery.js+ into +app/assets+ and it will be included automatically.
-The second is updating the various environment files with the correct default options. The following changes reflect the defaults in version 3.1.0.
+The third is updating the various environment files with the correct default options. The following changes reflect the defaults in version 3.1.0.
In +application.rb+:
@@ -725,8 +735,8 @@ The following should also be added to +Gemfile+:
# Gems used only for assets and not required
# in production environments by default.
group :assets do
- gem 'sass-rails', "~> 3.1.0"
- gem 'coffee-rails', "~> 3.1.0"
+ gem 'sass-rails', "~> 3.2.3"
+ gem 'coffee-rails', "~> 3.2.1"
gem 'uglifier'
end
</plain>
diff --git a/guides/source/contributing_to_ruby_on_rails.textile b/guides/source/contributing_to_ruby_on_rails.textile
index b52cd6c6b6..1dadce2083 100644
--- a/guides/source/contributing_to_ruby_on_rails.textile
+++ b/guides/source/contributing_to_ruby_on_rails.textile
@@ -474,7 +474,7 @@ 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.
+For simple fixes, the easiest way to backport your changes 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:
diff --git a/guides/source/initialization.textile b/guides/source/initialization.textile
index 0638bbed10..43d89eac4b 100644
--- a/guides/source/initialization.textile
+++ b/guides/source/initialization.textile
@@ -4,15 +4,22 @@ This guide explains the internals of the initialization process in Rails
as of Rails 4. It is an extremely in-depth guide and recommended for advanced Rails developers.
* Using +rails server+
-* Using Passenger
endprologue.
This guide goes through every method call that is
-required to boot up the Ruby on Rails stack for a default Rails 4 application, explaining each part in detail along the way. For this guide, we will be focusing on how the two most common methods (+rails server+ and Passenger) boot a Rails application.
+required to boot up the Ruby on Rails stack for a default Rails 4
+application, explaining each part in detail along the way. For this
+guide, we will be focusing on what happens when you execute +rails
+server+ to boot your app.
NOTE: Paths in this guide are relative to Rails or a Rails application unless otherwise specified.
+TIP: If you want to follow along while browsing the Rails "source
+code":https://github.com/rails/rails, we recommend that you use the +t+
+key binding to open the file finder inside github and find files
+quickly.
+
h3. Launch!
A Rails application is usually started with the command +rails server+.
@@ -32,7 +39,7 @@ require "rails/cli"
</ruby>
This file will first attempt to push the +railties/lib+ directory if
-present, and then require +rails/cli+.
+present, and then requires +rails/cli+.
h4. +railties/lib/rails/cli.rb+
@@ -121,8 +128,13 @@ exec RUBY, SCRIPT_RAILS, *ARGV if in_rails_application?
This is effectively the same as running +ruby script/rails [arguments]+, where +[arguments]+ at this point in time is simply "server".
+h3. Rails Initialization
+
+Only now we finally start the real initialization process, beginning
+with +script/rails+.
+
TIP: If you execute +script/rails+ directly from your Rails app you will
-avoid executing the code that we just described.
+skip executing all the code that we've just described.
h4. +script/rails+
@@ -239,12 +251,8 @@ module Rails
h4. +actionpack/lib/action_dispatch.rb+
-Action Dispatch is the routing component of the Rails framework. Other
-than the rouing itself, it adds
-functionalities like routing, session, and common middlewares.
-
-Action Dispatch itself is also responsible for loading Active Support, Action
-Pack, Active Model, and Rack.
+Action Dispatch is the routing component of the Rails framework.
+It adds functionalities like routing, session, and common middlewares.
h4. +rails/commands/server.rb+
@@ -352,8 +360,7 @@ h4. +config/application+
When +require APP_PATH+ is executed, +config/application.rb+ is loaded.
This is a file exists in your app and it's free for you to change based
-on your needs. Among other things, inside this file you load gems with
-bundler, and create your application namespace.
+on your needs.
h4. +Rails::Server#start+
@@ -513,7 +520,7 @@ require 'rails/all'
h4. +railties/lib/rails/all.rb+
-This file is responsible for requiring all the individual parts of Rails like so:
+This file is responsible for requiring all the individual frameworks of Rails:
<ruby>
require "rails"