mirror of
https://github.com/rails/rails.git
synced 2022-11-09 12:12:34 -05:00
Merge branch 'master' of github.com:lifo/docrails
This commit is contained in:
commit
1d89540686
9 changed files with 24 additions and 20 deletions
|
@ -100,8 +100,8 @@ branch.
|
|||
Run `rake install` to generate the gems and install them locally. Then try
|
||||
generating a new app and ensure that nothing explodes.
|
||||
|
||||
This will stop you looking silly when you push an RC to rubygems.org and then
|
||||
realise it is broken.
|
||||
This will stop you from looking silly when you push an RC to rubygems.org and
|
||||
then realise it is broken.
|
||||
|
||||
=== Release the gem.
|
||||
|
||||
|
@ -209,7 +209,7 @@ Repeat these steps until the CI is green.
|
|||
=== Manually trigger docs generation
|
||||
|
||||
We have a post-receive hook in GitHub that calls the docs server on pushes.
|
||||
Triggers generation and publication of edge docs, updates the contrib app,
|
||||
It triggers generation and publication of edge docs, updates the contrib app,
|
||||
and generates and publishes stable docs if a new stable tag is detected.
|
||||
|
||||
The hook unfortunately is not invoked by tag pushing, so once the new stable
|
||||
|
|
|
@ -42,7 +42,7 @@ module ActionDispatch
|
|||
# url_for(:controller => 'users',
|
||||
# :action => 'new',
|
||||
# :message => 'Welcome!',
|
||||
# :host => 'www.example.com') # Changed this.
|
||||
# :host => 'www.example.com')
|
||||
# # => "http://www.example.com/users/new?message=Welcome%21"
|
||||
#
|
||||
# By default, all controllers and views have access to a special version of url_for,
|
||||
|
@ -52,7 +52,7 @@ module ActionDispatch
|
|||
#
|
||||
# For convenience reasons, mailers provide a shortcut for ActionController::UrlFor#url_for.
|
||||
# So within mailers, you only have to type 'url_for' instead of 'ActionController::UrlFor#url_for'
|
||||
# in full. However, mailers don't have hostname information, and what's why you'll still
|
||||
# in full. However, mailers don't have hostname information, and that's why you'll still
|
||||
# have to specify the <tt>:host</tt> argument when generating URLs in mailers.
|
||||
#
|
||||
#
|
||||
|
|
|
@ -32,7 +32,7 @@ module ActionView
|
|||
# app/views/posts/index.atom.builder:
|
||||
# atom_feed do |feed|
|
||||
# feed.title("My great blog!")
|
||||
# feed.updated(@posts.first.created_at)
|
||||
# feed.updated(@posts.first.created_at) if @posts.any?
|
||||
#
|
||||
# @posts.each do |post|
|
||||
# feed.entry(post) do |entry|
|
||||
|
|
|
@ -41,7 +41,7 @@ module ActiveModel
|
|||
# You can choose not to have all three callbacks by passing a hash to the
|
||||
# define_model_callbacks method.
|
||||
#
|
||||
# define_model_callbacks :create, :only => :after, :before
|
||||
# define_model_callbacks :create, :only => [:after, :before]
|
||||
#
|
||||
# Would only create the after_create and before_create callback methods in your
|
||||
# class.
|
||||
|
|
|
@ -23,7 +23,7 @@ module ActiveResource
|
|||
# self.site = "http://37s.sunrise.i:3000"
|
||||
# end
|
||||
#
|
||||
# Person.new(:name => 'Ryan).post(:register) # POST /people/new/register.json
|
||||
# Person.new(:name => 'Ryan').post(:register) # POST /people/new/register.json
|
||||
# # => { :id => 1, :name => 'Ryan' }
|
||||
#
|
||||
# Person.find(1).put(:promote, :position => 'Manager') # PUT /people/1/promote.json
|
||||
|
|
|
@ -571,7 +571,7 @@ NOTE: Defined in +active_support/core_ext/module/attr_accessor_with_default.rb+.
|
|||
|
||||
h5. Internal Attributes
|
||||
|
||||
When you are defining an attribute in a class that is meant to be subclassed name collisions are a risk. That's remarkably important for libraries.
|
||||
When you are defining an attribute in a class that is meant to be subclassed, name collisions are a risk. That's remarkably important for libraries.
|
||||
|
||||
Active Support defines the macros +attr_internal_reader+, +attr_internal_writer+, and +attr_internal_accessor+. They behave like their Ruby built-in +attr_*+ counterparts, except they name the underlying instance variable in a way that makes collisions less likely.
|
||||
|
||||
|
|
|
@ -263,6 +263,8 @@ h4. Configuring Active Record
|
|||
|
||||
* +config.active_record.whitelist_attributes+ will create an empty whitelist of attributes available for mass-assignment security for all models in your app.
|
||||
|
||||
* +config.active_record.identity_map+ controls whether the identity map is enabled, and is false by default.
|
||||
|
||||
The MySQL adapter adds one additional configuration option:
|
||||
|
||||
* +ActiveRecord::ConnectionAdapters::MysqlAdapter.emulate_booleans+ controls whether Active Record will consider all +tinyint(1)+ columns in a MySQL database to be booleans and is true by default.
|
||||
|
|
|
@ -450,6 +450,8 @@ start a web server on your development machine. You can do this by running:
|
|||
$ rails server
|
||||
</shell>
|
||||
|
||||
TIP: Compiling CoffeeScript to JavaScript requires a JavaScript runtime and the absence of a runtime will give you an +execjs+ error. Usually Mac OS X and Windows come with a JavaScript runtime installed. +therubyracer+ and +therubyrhino+ are the commonly used runtimes for Ruby and JRuby respectively. You can also investigate a list of runtimes at "ExecJS":https://github.com/sstephenson/execjs.
|
||||
|
||||
This will fire up an instance of the WEBrick web server by default (Rails can
|
||||
also use several other web servers). To see your application in action, open a
|
||||
browser window and navigate to "http://localhost:3000":http://localhost:3000.
|
||||
|
|
|
@ -17,7 +17,7 @@ As of Rails 3, +script/server+ has become +rails server+. This was done to centr
|
|||
|
||||
h4. +bin/rails+
|
||||
|
||||
The actual +rails+ command is kept in _bin/rails_ at the and goes like this:
|
||||
The actual +rails+ command is kept in _bin/rails_:
|
||||
|
||||
<ruby>
|
||||
#!/usr/bin/env ruby
|
||||
|
@ -31,7 +31,7 @@ rescue LoadError
|
|||
end
|
||||
</ruby>
|
||||
|
||||
This file will attempt to load +rails/cli+ and if it cannot find it then add the +railties/lib+ path to the load path (+$:+) and will then try to require it again.
|
||||
This file will attempt to load +rails/cli+. If it cannot find it then +railties/lib+ is added to the load path (+$:+) before retrying.
|
||||
|
||||
h4. +railties/lib/rails/cli.rb+
|
||||
|
||||
|
@ -56,7 +56,7 @@ else
|
|||
end
|
||||
</ruby>
|
||||
|
||||
The +rbconfig+ file here is out of Ruby's standard library and provides us with the +RbConfig+ class which contains useful information dependent on how Ruby was compiled. We'll see this in use in +railties/lib/rails/script_rails_loader+.
|
||||
The +rbconfig+ file from the Ruby standard library provides us with the +RbConfig+ class which contains detailed information about the Ruby environment, including how Ruby was compiled. We can see this in use in +railties/lib/rails/script_rails_loader+.
|
||||
|
||||
<ruby>
|
||||
require 'pathname'
|
||||
|
@ -71,7 +71,7 @@ module Rails
|
|||
end
|
||||
</ruby>
|
||||
|
||||
The +rails/script_rails_loader+ file uses +RbConfig::Config+ to gather up the +bin_dir+ and +ruby_install_name+ values for the configuration which will result in a path such as +/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby+, which is the default path on Mac OS X. If you're running Windows the path may be something such as +C:/Ruby192/bin/ruby+. Anyway, the path on your system may be different, but the point of this is that it will point at the known ruby executable location for your install. The +RbConfig::CONFIG["EXEEXT"]+ will suffix this path with ".exe" if the script is running on Windows. This constant is used later on in +exec_script_rails!+. As for the +SCRIPT_RAILS+ constant, we'll see that when we get to the +in_rails_application?+ method.
|
||||
The +rails/script_rails_loader+ file uses +RbConfig::Config+ to obtain the +bin_dir+ and +ruby_install_name+ values for the configuration which together form the path to the Ruby interpreter. The +RbConfig::CONFIG["EXEEXT"]+ will suffix this path with ".exe" if the script is running on Windows. This constant is used later on in +exec_script_rails!+. As for the +SCRIPT_RAILS+ constant, we'll see that when we get to the +in_rails_application?+ method.
|
||||
|
||||
Back in +rails/cli+, the next line is this:
|
||||
|
||||
|
@ -79,7 +79,7 @@ Back in +rails/cli+, the next line is this:
|
|||
Rails::ScriptRailsLoader.exec_script_rails!
|
||||
</ruby>
|
||||
|
||||
This method is defined in +rails/script_rails_loader+ like this:
|
||||
This method is defined in +rails/script_rails_loader+:
|
||||
|
||||
<ruby>
|
||||
def self.exec_script_rails!
|
||||
|
@ -96,7 +96,7 @@ rescue SystemCallError
|
|||
end
|
||||
</ruby>
|
||||
|
||||
This method will first check if the current working directory (+cwd+) is a Rails application or is a subdirectory of one. The way to determine this is defined in the +in_rails_application?+ method like this:
|
||||
This method will first check if the current working directory (+cwd+) is a Rails application or a subdirectory of one. This is determined by the +in_rails_application?+ method:
|
||||
|
||||
<ruby>
|
||||
def self.in_rails_application?
|
||||
|
@ -104,7 +104,7 @@ def self.in_rails_application?
|
|||
end
|
||||
</ruby>
|
||||
|
||||
The +SCRIPT_RAILS+ constant defined earlier is used here, with +File.exists?+ checking for its presence in the current directory. If this method returns +false+, then +in_rails_application_subdirectory?+ will be used:
|
||||
The +SCRIPT_RAILS+ constant defined earlier is used here, with +File.exists?+ checking for its presence in the current directory. If this method returns +false+ then +in_rails_application_subdirectory?+ will be used:
|
||||
|
||||
<ruby>
|
||||
def self.in_rails_application_subdirectory?(path = Pathname.new(Dir.pwd))
|
||||
|
@ -112,17 +112,17 @@ def self.in_rails_application_subdirectory?(path = Pathname.new(Dir.pwd))
|
|||
end
|
||||
</ruby>
|
||||
|
||||
This climbs the directory tree until it reaches a path which contains a +script/rails+ file. If a directory is reached which contains this file then this line will run:
|
||||
This climbs the directory tree until it reaches a path which contains a +script/rails+ file. If a directory containing this file is reached then this line will run:
|
||||
|
||||
<ruby>
|
||||
exec RUBY, SCRIPT_RAILS, *ARGV if in_rails_application?
|
||||
</ruby>
|
||||
|
||||
This is effectively the same as doing +ruby script/rails [arguments]+. Where +[arguments]+ at this point in time is simply "server".
|
||||
This is effectively the same as running +ruby script/rails [arguments]+, where +[arguments]+ at this point in time is simply "server".
|
||||
|
||||
h4. +script/rails+
|
||||
|
||||
This file looks like this:
|
||||
This file is as follows:
|
||||
|
||||
<ruby>
|
||||
APP_PATH = File.expand_path('../../config/application', __FILE__)
|
||||
|
@ -130,7 +130,7 @@ require File.expand_path('../../config/boot', __FILE__)
|
|||
require 'rails/commands'
|
||||
</ruby>
|
||||
|
||||
The +APP_PATH+ constant here will be used later in +rails/commands+. The +config/boot+ file that +script/rails+ references is the +config/boot.rb+ file in our application which is responsible for loading Bundler and setting it up.
|
||||
The +APP_PATH+ constant will be used later in +rails/commands+. The +config/boot+ file referenced here is the +config/boot.rb+ file in our application which is responsible for loading Bundler and setting it up.
|
||||
|
||||
h4. +config/boot.rb+
|
||||
|
||||
|
|
Loading…
Reference in a new issue