mirror of https://github.com/rails/rails
Remove references to Rails versions.
There's no reason for guides to reference old behaviors. They should be current as of the versions of Rails that they ship with, and including older information just clutters thing. I discussed this change with @fxn and he agrees.
This commit is contained in:
parent
e618adbcab
commit
ed78770b1a
|
@ -828,7 +828,7 @@ NOTE: Certain exceptions are only rescuable from the `ApplicationController` cla
|
|||
Force HTTPS protocol
|
||||
--------------------
|
||||
|
||||
Sometime you might want to force a particular controller to only be accessible via an HTTPS protocol for security reasons. Since Rails 3.1 you can now use the `force_ssl` method in your controller to enforce that:
|
||||
Sometime you might want to force a particular controller to only be accessible via an HTTPS protocol for security reasons. You can use the `force_ssl` method in your controller to enforce that:
|
||||
|
||||
```ruby
|
||||
class DinnerController
|
||||
|
|
|
@ -109,7 +109,7 @@ When you call the `mail` method now, Action Mailer will detect the two templates
|
|||
|
||||
#### Wire It Up So That the System Sends the Email When a User Signs Up
|
||||
|
||||
There are several ways to do this, some people create Rails Observers to fire off emails, others do it inside of the User Model. However, in Rails 3, mailers are really just another way to render a view. Instead of rendering a view and sending out the HTTP protocol, they are just sending it out through the Email protocols instead. Due to this, it makes sense to just have your controller tell the mailer to send an email when a user is successfully created.
|
||||
There are several ways to do this, some people create Rails Observers to fire off emails, others do it inside of the User Model. However, mailers are really just another way to render a view. Instead of rendering a view and sending out the HTTP protocol, they are just sending it out through the Email protocols instead. Due to this, it makes sense to just have your controller tell the mailer to send an email when a user is successfully created.
|
||||
|
||||
Setting this up is painfully simple.
|
||||
|
||||
|
@ -149,8 +149,6 @@ This provides a much simpler implementation that does not require the registerin
|
|||
|
||||
The method `welcome_email` returns a `Mail::Message` object which can then just be told `deliver` to send itself out.
|
||||
|
||||
NOTE: In previous versions of Rails, you would call `deliver_welcome_email` or `create_welcome_email`. This has been deprecated in Rails 3.0 in favour of just calling the method name itself.
|
||||
|
||||
WARNING: Sending out an email should only take a fraction of a second. If you are planning on sending out many emails, or you have a slow domain resolution service, you might want to investigate using a background process like Delayed Job.
|
||||
|
||||
### Auto encoding header values
|
||||
|
|
|
@ -1263,10 +1263,8 @@ Creates a field set for grouping HTML form elements.
|
|||
|
||||
Creates a file upload field.
|
||||
|
||||
Prior to Rails 3.1, if you are using file uploads, then you will need to set the multipart option for the form tag. Rails 3.1+ does this automatically.
|
||||
|
||||
```html+erb
|
||||
<%= form_tag {action: "post"}, {multipart: true} do %>
|
||||
<%= form_tag {action: "post"} do %>
|
||||
<label for="file">File to Upload</label> <%= file_field_tag "file" %>
|
||||
<%= submit_tag %>
|
||||
<% end %>
|
||||
|
|
|
@ -1222,8 +1222,6 @@ You can specify an exclamation point (`!`) on the end of the dynamic finders to
|
|||
|
||||
If you want to find both by name and locked, you can chain these finders together by simply typing "`and`" between the fields. For example, `Client.find_by_first_name_and_locked("Ryan", true)`.
|
||||
|
||||
WARNING: Up to and including Rails 3.1, when the number of arguments passed to a dynamic finder method is lesser than the number of fields, say `Client.find_by_name_and_locked("Ryan")`, the behavior is to pass `nil` as the missing argument. This is **unintentional** and this behavior has been changed in Rails 3.2 to throw an `ArgumentError`.
|
||||
|
||||
Find or Build a New Object
|
||||
--------------------------
|
||||
|
||||
|
|
|
@ -1120,8 +1120,6 @@ C.subclasses # => [B, D]
|
|||
|
||||
The order in which these classes are returned is unspecified.
|
||||
|
||||
WARNING: This method is redefined in some Rails core classes but should be all compatible in Rails 3.1.
|
||||
|
||||
NOTE: Defined in `active_support/core_ext/class/subclasses.rb`.
|
||||
|
||||
#### `descendants`
|
||||
|
@ -1157,7 +1155,7 @@ Inserting data into HTML templates needs extra care. For example, you can't just
|
|||
|
||||
#### Safe Strings
|
||||
|
||||
Active Support has the concept of <i>(html) safe</i> strings since Rails 3. A safe string is one that is marked as being insertable into HTML as is. It is trusted, no matter whether it has been escaped or not.
|
||||
Active Support has the concept of <i>(html) safe</i> strings. A safe string is one that is marked as being insertable into HTML as is. It is trusted, no matter whether it has been escaped or not.
|
||||
|
||||
Strings are considered to be <i>unsafe</i> by default:
|
||||
|
||||
|
@ -1194,10 +1192,10 @@ Safe arguments are directly appended:
|
|||
"".html_safe + "<".html_safe # => "<"
|
||||
```
|
||||
|
||||
These methods should not be used in ordinary views. In Rails 3 unsafe values are automatically escaped:
|
||||
These methods should not be used in ordinary views. Unsafe values are automatically escaped:
|
||||
|
||||
```erb
|
||||
<%= @review.title %> <%# fine in Rails 3, escaped if needed %>
|
||||
<%= @review.title %> <%# fine, escaped if needed %>
|
||||
```
|
||||
|
||||
To insert something verbatim use the `raw` helper rather than calling `html_safe`:
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
The Asset Pipeline
|
||||
==================
|
||||
|
||||
This guide covers the asset pipeline introduced in Rails 3.1.
|
||||
This guide covers the asset pipeline.
|
||||
|
||||
After reading this guide, you will know:
|
||||
|
||||
|
@ -18,11 +18,9 @@ What is the Asset Pipeline?
|
|||
|
||||
The asset pipeline provides a framework to concatenate and minify or compress JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.
|
||||
|
||||
Prior to Rails 3.1 these features were added through third-party Ruby libraries such as Jammit and Sprockets. Rails 3.1 is integrated with Sprockets through Action Pack which depends on the `sprockets` gem, by default.
|
||||
|
||||
Making the asset pipeline a core feature of Rails means that all developers can benefit from the power of having their assets pre-processed, compressed and minified by one central library, Sprockets. This is part of Rails' "fast by default" strategy as outlined by DHH in his keynote at RailsConf 2011.
|
||||
|
||||
In Rails 3.1, the asset pipeline is enabled by default. It can be disabled in `config/application.rb` by putting this line inside the application class definition:
|
||||
The asset pipeline is enabled by default. It can be disabled in `config/application.rb` by putting this line inside the application class definition:
|
||||
|
||||
```ruby
|
||||
config.assets.enabled = false
|
||||
|
@ -287,8 +285,6 @@ For example, a new Rails application includes a default `app/assets/javascripts/
|
|||
|
||||
In JavaScript files, the directives begin with `//=`. In this case, the file is using the `require` and the `require_tree` directives. The `require` directive is used to tell Sprockets the files that you wish to require. Here, you are requiring the files `jquery.js` and `jquery_ujs.js` that are available somewhere in the search path for Sprockets. You need not supply the extensions explicitly. Sprockets assumes you are requiring a `.js` file when done from within a `.js` file.
|
||||
|
||||
NOTE. In Rails 3.1 the `jquery-rails` gem provides the `jquery.js` and `jquery_ujs.js` files via the asset pipeline. You won't see them in the application tree.
|
||||
|
||||
The `require_tree` directive tells Sprockets to recursively include _all_ JavaScript files in the specified directory into the output. These paths must be specified relative to the manifest file. You can also use the `require_directory` directive which includes all JavaScript files only in the directory specified, without recursion.
|
||||
|
||||
Directives are processed top to bottom, but the order in which files are included by `require_tree` is unspecified. You should not rely on any particular order among those. If you need to ensure some particular JavaScript ends up above some other in the concatenated file, require the prerequisite file first in the manifest. Note that the family of `require` directives prevents files from being included twice in the output.
|
||||
|
@ -665,7 +661,7 @@ This can be changed to something else:
|
|||
config.assets.prefix = "/some_other_path"
|
||||
```
|
||||
|
||||
This is a handy option if you are updating an existing project (pre Rails 3.1) that already uses this path or you wish to use this path for a new resource.
|
||||
This is a handy option if you are updating an older project that didn't use the asset pipeline and that already uses this path or you wish to use this path for a new resource.
|
||||
|
||||
### X-Sendfile Headers
|
||||
|
||||
|
|
|
@ -135,8 +135,6 @@ These configuration methods are to be called on a `Rails::Railtie` object, such
|
|||
|
||||
### Configuring Assets
|
||||
|
||||
Rails 3.1 and up, by default, is set up to use the `sprockets` gem to manage assets within an application. This gem concatenates and compresses assets in order to make serving them much less painful.
|
||||
|
||||
* `config.assets.enabled` a flag that controls whether the asset pipeline is enabled. It is explicitly initialized in `config/application.rb`.
|
||||
|
||||
* `config.assets.compress` a flag that enables the compression of compiled assets. It is explicitly set to true in `config/production.rb`.
|
||||
|
@ -165,7 +163,7 @@ Rails 3.1 and up, by default, is set up to use the `sprockets` gem to manage ass
|
|||
|
||||
### Configuring Generators
|
||||
|
||||
Rails 3 allows you to alter what generators are used with the `config.generators` method. This method takes a block:
|
||||
Rails allows you to alter what generators are used with the `config.generators` method. This method takes a block:
|
||||
|
||||
```ruby
|
||||
config.generators do |g|
|
||||
|
|
|
@ -35,7 +35,7 @@ Finally, engines would not have been possible without the work of James Adam, Pi
|
|||
Generating an engine
|
||||
--------------------
|
||||
|
||||
To generate an engine with Rails 3.2, you will need to run the plugin generator and pass it options as appropriate to the need. For the "blorgh" example, you will need to create a "mountable" engine, running this command in a terminal:
|
||||
To generate an engine, you will need to run the plugin generator and pass it options as appropriate to the need. For the "blorgh" example, you will need to create a "mountable" engine, running this command in a terminal:
|
||||
|
||||
```bash
|
||||
$ rails plugin new blorgh --mountable
|
||||
|
|
|
@ -594,8 +594,6 @@ The following two forms both upload a file.
|
|||
<% end %>
|
||||
```
|
||||
|
||||
NOTE: Since Rails 3.1, forms rendered using `form_for` have their encoding set to `multipart/form-data` automatically once a `file_field` is used inside the block. Previous versions required you to set this explicitly.
|
||||
|
||||
Rails provides the usual pair of helpers: the barebones `file_field_tag` and the model oriented `file_field`. The only difference with other helpers is that you cannot set a default value for file inputs as this would have no meaning. As you would expect in the first case the uploaded file is in `params[:picture]` and in the second case in `params[:person][:picture]`.
|
||||
|
||||
### What Gets Uploaded
|
||||
|
|
|
@ -15,8 +15,6 @@ After reading this guide, you will know:
|
|||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
NOTE: This guide is about generators in Rails 3, previous versions are not covered.
|
||||
|
||||
First Contact
|
||||
-------------
|
||||
|
||||
|
|
|
@ -160,21 +160,6 @@ def update
|
|||
end
|
||||
```
|
||||
|
||||
To be explicit, you can use `render` with the `:action` option (though this is no longer necessary in Rails 3.0):
|
||||
|
||||
```ruby
|
||||
def update
|
||||
@book = Book.find(params[:id])
|
||||
if @book.update_attributes(params[:book])
|
||||
redirect_to(@book)
|
||||
else
|
||||
render action: "edit"
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
WARNING: Using `render` with `:action` is a frequent source of confusion for Rails newcomers. The specified action is used to determine which view to render, but Rails does _not_ run any of the code for that action in the controller. Any instance variables that you require in the view must be set up in the current action before calling `render`.
|
||||
|
||||
#### Rendering an Action's Template from Another Controller
|
||||
|
||||
What if you want to render a template from an entirely different controller from the one that contains the action code? You can also do that with `render`, which accepts the full path (relative to `app/views`) of the template to render. For example, if you're running code in an `AdminProductsController` that lives in `app/controllers/admin`, you can render the results of an action to a template in `app/views/products` this way:
|
||||
|
@ -674,7 +659,7 @@ There are three tag options available for the `auto_discovery_link_tag`:
|
|||
|
||||
The `javascript_include_tag` helper returns an HTML `script` tag for each source provided.
|
||||
|
||||
If you are using Rails with the [Asset Pipeline](asset_pipeline.html) enabled, this helper will generate a link to `/assets/javascripts/` rather than `public/javascripts` which was used in earlier versions of Rails. This link is then served by the Sprockets gem, which was introduced in Rails 3.1.
|
||||
If you are using Rails with the [Asset Pipeline](asset_pipeline.html) enabled, this helper will generate a link to `/assets/javascripts/` rather than `public/javascripts` which was used in earlier versions of Rails. This link is then served by the asset pipeline.
|
||||
|
||||
A JavaScript file within a Rails application or Rails engine goes in one of three locations: `app/assets`, `lib/assets` or `vendor/assets`. These locations are explained in detail in the [Asset Organization section in the Asset Pipeline Guide](asset_pipeline.html#asset-organization)
|
||||
|
||||
|
@ -843,7 +828,7 @@ You can even use dynamic paths such as `cache/#{current_site}/main/display`.
|
|||
|
||||
The `image_tag` helper builds an HTML `<img />` tag to the specified file. By default, files are loaded from `public/images`.
|
||||
|
||||
WARNING: Note that you must specify the extension of the image. Previous versions of Rails would allow you to just use the image name and would append `.png` if no extension was given but Rails 3.0 does not.
|
||||
WARNING: Note that you must specify the extension of the image.
|
||||
|
||||
```erb
|
||||
<%= image_tag "header.png" %>
|
||||
|
@ -1091,8 +1076,6 @@ Every partial also has a local variable with the same name as the partial (minus
|
|||
|
||||
Within the `customer` partial, the `customer` variable will refer to `@new_customer` from the parent view.
|
||||
|
||||
WARNING: In previous versions of Rails, the default local variable would look for an instance variable with the same name as the partial in the parent. This behavior was deprecated in 2.3 and has been removed in Rails 3.0.
|
||||
|
||||
If you have an instance of a model to render into a partial, you can use a shorthand syntax:
|
||||
|
||||
```erb
|
||||
|
@ -1120,7 +1103,7 @@ Partials are very useful in rendering collections. When you pass a collection to
|
|||
|
||||
When a partial is called with a pluralized collection, then the individual instances of the partial have access to the member of the collection being rendered via a variable named after the partial. In this case, the partial is `_product`, and within the `_product` partial, you can refer to `product` to get the instance that is being rendered.
|
||||
|
||||
In Rails 3.0, there is also a shorthand for this. Assuming `@products` is a collection of `product` instances, you can simply write this in the `index.html.erb` to produce the same result:
|
||||
There is also a shorthand for this. Assuming `@products` is a collection of `product` instances, you can simply write this in the `index.html.erb` to produce the same result:
|
||||
|
||||
```html+erb
|
||||
<h1>Products</h1>
|
||||
|
|
|
@ -27,16 +27,13 @@ goodness.
|
|||
Setup
|
||||
-----
|
||||
|
||||
_"vendored plugins"_ were available in previous versions of Rails, but they are deprecated in
|
||||
Rails 3.2, and will not be available in the future.
|
||||
|
||||
Currently, Rails plugins are built as gems, _gemified plugins_. They can be shared across
|
||||
different rails applications using RubyGems and Bundler if desired.
|
||||
|
||||
### Generate a gemified plugin.
|
||||
|
||||
|
||||
Rails 3.1 ships with a `rails plugin new` command which creates a
|
||||
Rails ships with a `rails plugin new` command which creates a
|
||||
skeleton for developing any kind of Rails extension with the ability
|
||||
to run integration tests using a dummy Rails application. See usage
|
||||
and options by asking for help:
|
||||
|
|
|
@ -733,12 +733,6 @@ get '*a/foo/*b', to: 'test#index'
|
|||
|
||||
would match `zoo/woo/foo/bar/baz` with `params[:a]` equals `'zoo/woo'`, and `params[:b]` equals `'bar/baz'`.
|
||||
|
||||
NOTE: Starting from Rails 3.1, wildcard segments will always match the optional format segment by default. For example if you have this route:
|
||||
|
||||
```ruby
|
||||
get '*pages', to: 'pages#show'
|
||||
```
|
||||
|
||||
NOTE: By requesting `'/foo/bar.json'`, your `params[:pages]` will be equals to `'foo/bar'` with the request format of JSON. If you want the old 3.0.x behavior back, you could supply `format: false` like this:
|
||||
|
||||
```ruby
|
||||
|
|
Loading…
Reference in New Issue