diff options
Diffstat (limited to 'guides/source')
| -rw-r--r-- | guides/source/action_controller_overview.md | 4 | ||||
| -rw-r--r-- | guides/source/action_view_overview.md | 40 | ||||
| -rw-r--r-- | guides/source/active_record_querying.md | 2 | ||||
| -rw-r--r-- | guides/source/asset_pipeline.md | 6 | ||||
| -rw-r--r-- | guides/source/engines.md | 4 | ||||
| -rw-r--r-- | guides/source/getting_started.md | 87 | ||||
| -rw-r--r-- | guides/source/i18n.md | 7 | ||||
| -rw-r--r-- | guides/source/layouts_and_rendering.md | 4 | ||||
| -rw-r--r-- | guides/source/rails_application_templates.md | 19 | ||||
| -rw-r--r-- | guides/source/rails_on_rack.md | 2 | ||||
| -rw-r--r-- | guides/source/upgrading_ruby_on_rails.md | 10 |
11 files changed, 127 insertions, 58 deletions
diff --git a/guides/source/action_controller_overview.md b/guides/source/action_controller_overview.md index f1600fe458..f2abd833aa 100644 --- a/guides/source/action_controller_overview.md +++ b/guides/source/action_controller_overview.md @@ -160,7 +160,7 @@ NOTE: Support for parsing XML parameters has been extracted into a gem named `ac The `params` hash will always contain the `:controller` and `:action` keys, but you should use the methods `controller_name` and `action_name` instead to access these values. Any other parameters defined by the routing, such as `:id` will also be available. As an example, consider a listing of clients where the list can show either active or inactive clients. We can add a route which captures the `:status` parameter in a "pretty" URL: ```ruby -match '/clients/:status' => 'clients#index', foo: 'bar' +get '/clients/:status' => 'clients#index', foo: 'bar' ``` In this case, when a user opens the URL `/clients/active`, `params[:status]` will be set to "active". When this route is used, `params[:foo]` will also be set to "bar" just like it was passed in the query string. In the same way `params[:action]` will contain "index". @@ -346,7 +346,7 @@ Your application has a session for each user in which you can store small amount All session stores use a cookie to store a unique ID for each session (you must use a cookie, Rails will not allow you to pass the session ID in the URL as this is less secure). -For most stores, this ID is used to look up the session data on the server, e.g. in a database table. There is one exception, and that is the default and recommended session store - the CookieStore - which stores all session data in the cookie itself (the ID is still available to you if you need it). This has the advantage of being very lightweight and it requires zero setup in a new application in order to use the session. The cookie data is cryptographically signed to make it tamper-proof, but it is not encrypted, so anyone with access to it can read its contents but not edit it (Rails will not accept it if it has been edited). +For most stores, this ID is used to look up the session data on the server, e.g. in a database table. There is one exception, and that is the default and recommended session store - the CookieStore - which stores all session data in the cookie itself (the ID is still available to you if you need it). This has the advantage of being very lightweight and it requires zero setup in a new application in order to use the session. The cookie data is cryptographically signed to make it tamper-proof. And it is also encrypted so anyone with access to it can't read its contents. (Rails will not accept it if it has been edited). The CookieStore can store around 4kB of data — much less than the others — but this is usually enough. Storing large amounts of data in the session is discouraged no matter which session store your application uses. You should especially avoid storing complex objects (anything other than basic Ruby objects, the most common example being model instances) in the session, as the server might not be able to reassemble them between requests, which will result in an error. diff --git a/guides/source/action_view_overview.md b/guides/source/action_view_overview.md index b3fc61f386..bd8e5ce4f2 100644 --- a/guides/source/action_view_overview.md +++ b/guides/source/action_view_overview.md @@ -941,9 +941,9 @@ Creates a form and a scope around a specific model object that is used as a base ```html+erb <%= form_for @post do |f| %> <%= f.label :title, 'Title' %>: - <%= f.text_field :title %><br /> + <%= f.text_field :title %><br> <%= f.label :body, 'Body' %>: - <%= f.text_area :body %><br /> + <%= f.text_area :body %><br> <% end %> ``` @@ -1006,6 +1006,24 @@ text_field(:post, :title) # => <input type="text" id="post_title" name="post[title]" value="#{@post.title}" /> ``` +#### email_field + +Returns an input tag of the "email" type tailored for accessing a specified attribute. + +```ruby +email_field(:user, :email) +# => <input type="email" id="user_email" name="user[email]" value="#{@user.email}" /> +``` + +#### url_field + +Returns an input tag of the "url" type tailored for accessing a specified attribute. + +```ruby +url_field(:user, :url) +# => <input type="url" id="user_url" name="user[url]" value="#{@user.url}" /> +``` + ### FormOptionsHelper Provides a number of methods for turning different kinds of containers into a set of option tags. @@ -1372,6 +1390,24 @@ text_field_tag 'name' # => <input id="name" name="name" type="text" /> ``` +#### email_field_tag + +Creates a standard input field of email type. + +```ruby +email_field_tag 'email' +# => <input id="email" name="email" type="email" /> +``` + +#### url_field_tag + +Creates a standard input field of url type. + +```ruby +url_field_tag 'url' +# => <input id="url" name="url" type="url" /> +``` + #### date_field_tag Creates a standard input field of date type. diff --git a/guides/source/active_record_querying.md b/guides/source/active_record_querying.md index 407e779f9f..031a203f08 100644 --- a/guides/source/active_record_querying.md +++ b/guides/source/active_record_querying.md @@ -1210,9 +1210,7 @@ class User < ActiveRecord::Base scope :active, -> { where state: 'active' } scope :inactive, -> { where state: 'inactive' } end -``` -```ruby User.active.inactive # => SELECT "users".* FROM "users" WHERE "users"."state" = 'active' AND "users"."state" = 'inactive' ``` diff --git a/guides/source/asset_pipeline.md b/guides/source/asset_pipeline.md index b68c24acfd..a6e3d3b0ac 100644 --- a/guides/source/asset_pipeline.md +++ b/guides/source/asset_pipeline.md @@ -69,12 +69,12 @@ Rails' old strategy was to append a date-based query string to every asset linke The query string strategy has several disadvantages: -1. **Not all caches will reliably cache content where the filename only differs by query parameters**<br /> +1. **Not all caches will reliably cache content where the filename only differs by query parameters**<br> [Steve Souders recommends](http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/), "...avoiding a querystring for cacheable resources". He found that in this case 5-20% of requests will not be cached. Query strings in particular do not work at all with some CDNs for cache invalidation. -2. **The file name can change between nodes in multi-server environments.**<br /> +2. **The file name can change between nodes in multi-server environments.**<br> The default query string in Rails 2.x is based on the modification time of the files. When assets are deployed to a cluster, there is no guarantee that the timestamps will be the same, resulting in different values being used depending on which server handles the request. -3. **Too much cache invalidation**<br /> +3. **Too much cache invalidation**<br> When static assets are deployed with each new release of code, the mtime(time of last modification) of _all_ these files changes, forcing all remote clients to fetch them again, even when the content of those assets has not changed. Fingerprinting fixes these problems by avoiding query strings, and by ensuring that filenames are consistent based on their content. diff --git a/guides/source/engines.md b/guides/source/engines.md index bc66ed256e..d714f84731 100644 --- a/guides/source/engines.md +++ b/guides/source/engines.md @@ -346,7 +346,7 @@ Next, the partial that this line will render needs to exist. Create a new direct <h3>New comment</h3> <%= form_for [@post, @post.comments.build] do |f| %> <p> - <%= f.label :text %><br /> + <%= f.label :text %><br> <%= f.text_area :text %> </p> <%= f.submit %> @@ -515,7 +515,7 @@ First, the `author_name` text field needs to be added to the `app/views/blorgh/p ```html+erb <div class="field"> - <%= f.label :author_name %><br /> + <%= f.label :author_name %><br> <%= f.text_field :author_name %> </div> ``` diff --git a/guides/source/getting_started.md b/guides/source/getting_started.md index 26360e815b..9b2fa315a1 100644 --- a/guides/source/getting_started.md +++ b/guides/source/getting_started.md @@ -138,7 +138,7 @@ application. Most of the work in this tutorial will happen in the `app/` folder, |config/|Configure your application's runtime rules, routes, database, and more. This is covered in more detail in [Configuring Rails Applications](configuring.html)| |config.ru|Rack configuration for Rack based servers used to start the application.| |db/|Contains your current database schema, as well as the database migrations.| -|Gemfile<br />Gemfile.lock|These files allow you to specify what gem dependencies are needed for your Rails application. These files are used by the Bundler gem. For more information about Bundler, see [the Bundler website](http://gembundler.com) | +|Gemfile<br>Gemfile.lock|These files allow you to specify what gem dependencies are needed for your Rails application. These files are used by the Bundler gem. For more information about Bundler, see [the Bundler website](http://gembundler.com) | |lib/|Extended modules for your application.| |log/|Application log files.| |public/|The only folder seen to the world as-is. Contains the static files and compiled assets.| @@ -264,11 +264,14 @@ Blog::Application.routes.draw do end ``` -If you run `rake routes`, you'll see that all the routes for the -standard RESTful actions. +If you run `rake routes`, you'll see that it has defined routes for all the +standard RESTful actions. The meaning of the prefix column (and other columns) +will be seen later, but for now notice that Rails has inferred the +singular form `post` and makes meaningful use of the distinction. ```bash $ rake routes + Prefix Verb URI Pattern Controller#Action posts GET /posts(.:format) posts#index POST /posts(.:format) posts#create new_post GET /posts/new(.:format) posts#new @@ -394,9 +397,27 @@ Edit the `form_for` line inside `app/views/posts/new.html.erb` to look like this <%= form_for :post, url: posts_path do |f| %> ``` -In this example, the `posts_path` helper is passed to the `:url` option. What Rails will do with this is that it will point the form to the `create` action of the current controller, the `PostsController`, and will send a `POST` request to that route. - -By using the `post` method rather than the `get` method, Rails will define a route that will only respond to POST methods. The POST method is the typical method used by forms all over the web. +In this example, the `posts_path` helper is passed to the `:url` option. +To see what Rails will do with this, we look back at the output of +`rake routes`: +```bash +$ rake routes + Prefix Verb URI Pattern Controller#Action + posts GET /posts(.:format) posts#index + POST /posts(.:format) posts#create + new_post GET /posts/new(.:format) posts#new +edit_post GET /posts/:id/edit(.:format) posts#edit + post GET /posts/:id(.:format) posts#show + PATCH /posts/:id(.:format) posts#update + PUT /posts/:id(.:format) posts#update + DELETE /posts/:id(.:format) posts#destroy + root / welcome#index +``` +The `posts_path` helper tells Rails to point the form +to the URI Pattern associated with the `posts` prefix; and +the form will (by default) send a `POST` request +to that route. This is associated with the +`create` action of the current controller, the `PostsController`. With the form and its associated route defined, you will be able to fill in the form and then click the submit button to begin the process of creating a new post, so go ahead and do that. When you submit the form, you should see a familiar error: @@ -531,27 +552,19 @@ and change the `create` action to look like this: ```ruby def create - @post = Post.new(post_params) + @post = Post.new(params[:post]) @post.save redirect_to @post end - -private - def post_params - params.require(:post).permit(:title, :text) - end ``` Here's what's going on: every Rails model can be initialized with its respective attributes, which are automatically mapped to the respective -database columns. In the first line we do just that (remember that -`post_params` contains the attributes we're interested in). Then, -`@post.save` is responsible for saving the model in the database. -Finally, we redirect the user to the `show` action, -which we'll define later. - -TIP: Note that `def post_params` is private. This new approach prevents an attacker from setting the model's attributes by manipulating the hash passed to the model. For more information, refer to [this blog post about Strong Parameters](http://weblog.rubyonrails.org/2012/3/21/strong-parameters/). +database columns. In the first line we do just that +(remember that `params[:post]` contains the attributes we're interested in). +Then, `@post.save` is responsible for saving the model in the database. +Finally, we redirect the user to the `show` action, which we'll define later. TIP: As we'll see later, `@post.save` returns a boolean indicating whether the model was saved or not. @@ -631,6 +644,11 @@ Visit <http://localhost:3000/posts/new> and give it a try!  +TIP: Note that `def post_params` is private. This new approach prevents an attacker from +setting the model's attributes by manipulating the hash passed to the model. +For more information, refer to +[this blog post about Strong Parameters](http://weblog.rubyonrails.org/2012/3/21/strong-parameters/). + ### Listing all posts We still need a way to list all our posts, so let's do that. @@ -726,7 +744,7 @@ TIP: In development mode (which is what you're working in by default), Rails reloads your application with every browser request, so there's no need to stop and restart the web server when a change is made. -### Allowing the update of fields +### Adding Some Validation The model file, `app/models/post.rb` is about as simple as it can get: @@ -741,8 +759,6 @@ your Rails models for free, including basic database CRUD (Create, Read, Update, Destroy) operations, data validation, as well as sophisticated search support and the ability to relate multiple models to one another. -### Adding Some Validation - Rails includes methods to help you validate the data that you send to models. Open the `app/models/post.rb` file and edit it: @@ -1021,9 +1037,14 @@ content: ``` Everything except for the `form_for` declaration remained the same. -How `form_for` can figure out the right `action` and `method` attributes -when building the form will be explained in just a moment. For now, let's update the -`app/views/posts/new.html.erb` view to use this new partial, rewriting it +The reason we can use this shorter, simpler `form_for` declaration +to stand in for either of the other forms is that `@post` is a *resource* +corresponding to a full set of RESTful routes, and Rails is able to infer +which URI and method to use. +For more information about this use of `form_for`, see +[Resource-oriented style](//api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-form_for-label-Resource-oriented+style). + +Now, let's update the `app/views/posts/new.html.erb` view to use this new partial, rewriting it completely: ```html+erb @@ -1294,11 +1315,11 @@ So first, we'll wire up the Post show template <h2>Add a comment:</h2> <%= form_for([@post, @post.comments.build]) do |f| %> <p> - <%= f.label :commenter %><br /> + <%= f.label :commenter %><br> <%= f.text_field :commenter %> </p> <p> - <%= f.label :body %><br /> + <%= f.label :body %><br> <%= f.text_area :body %> </p> <p> @@ -1374,11 +1395,11 @@ template. This is where we want the comment to show, so let's add that to the <h2>Add a comment:</h2> <%= form_for([@post, @post.comments.build]) do |f| %> <p> - <%= f.label :commenter %><br /> + <%= f.label :commenter %><br> <%= f.text_field :commenter %> </p> <p> - <%= f.label :body %><br /> + <%= f.label :body %><br> <%= f.text_area :body %> </p> <p> @@ -1440,11 +1461,11 @@ following: <h2>Add a comment:</h2> <%= form_for([@post, @post.comments.build]) do |f| %> <p> - <%= f.label :commenter %><br /> + <%= f.label :commenter %><br> <%= f.text_field :commenter %> </p> <p> - <%= f.label :body %><br /> + <%= f.label :body %><br> <%= f.text_area :body %> </p> <p> @@ -1470,11 +1491,11 @@ create a file `app/views/comments/_form.html.erb` containing: ```html+erb <%= form_for([@post, @post.comments.build]) do |f| %> <p> - <%= f.label :commenter %><br /> + <%= f.label :commenter %><br> <%= f.text_field :commenter %> </p> <p> - <%= f.label :body %><br /> + <%= f.label :body %><br> <%= f.text_area :body %> </p> <p> diff --git a/guides/source/i18n.md b/guides/source/i18n.md index 062da3877b..2b116c337a 100644 --- a/guides/source/i18n.md +++ b/guides/source/i18n.md @@ -21,6 +21,11 @@ This guide will walk you through the I18n API and contains a tutorial on how to After reading this guide, you will know: +* How I18n works in Ruby on Rails +* How to correctly use I18n into a RESTful application in various ways +* How to use I18n to translate ActiveRecord errors or ActionMailer E-mail subjects +* Some other tools to go further with the translation process of your application + -------------------------------------------------------------------------------- NOTE: The Ruby I18n framework provides you with all necessary means for internationalization/localization of your Rails application. You may, however, use any of various plugins and extensions available, which add additional functionality or features. See the Rails [I18n Wiki](http://rails-i18n.org/wiki) for more information. @@ -253,7 +258,7 @@ You would probably need to map URLs like these: ```ruby # config/routes.rb -match '/:locale' => 'dashboard#index' +get '/:locale' => 'dashboard#index' ``` Do take special care about the **order of your routes**, so this route declaration does not "eat" other ones. (You may want to add it directly before the `root :to` declaration.) diff --git a/guides/source/layouts_and_rendering.md b/guides/source/layouts_and_rendering.md index 5908801bc9..5b6e5387ff 100644 --- a/guides/source/layouts_and_rendering.md +++ b/guides/source/layouts_and_rendering.md @@ -88,7 +88,7 @@ If we want to display the properties of all the books in our view, we can do so <% end %> </table> -<br /> +<br> <%= link_to "New book", new_book_path %> ``` @@ -1026,7 +1026,7 @@ You can also pass local variables into partials, making them even more powerful ```html+erb <%= form_for(zone) do |f| %> <p> - <b>Zone name</b><br /> + <b>Zone name</b><br> <%= f.text_field :name %> </p> <p> diff --git a/guides/source/rails_application_templates.md b/guides/source/rails_application_templates.md index f8062a1f7c..0c70f379be 100644 --- a/guides/source/rails_application_templates.md +++ b/guides/source/rails_application_templates.md @@ -227,3 +227,22 @@ git :init git add: "." git commit: "-a -m 'Initial commit'" ``` + +Advanced Usage +-------------- + +The application template is evaluated in the context of a +`Rails::Generators::AppGenerator` instance. It uses the `apply` action +provided by +[Thor](https://github.com/erikhuda/thor/blob/master/lib/thor/actions.rb#L207). +This means you can extend and change the instance to match your needs. + +For example by overwriting the `source_paths` method to contain the +location of your template. Now methods like `copy_file` will accept +relative paths to your template's location. + +```ruby +def source_paths + [File.expand_path(File.dirname(__FILE__))] +end +``` diff --git a/guides/source/rails_on_rack.md b/guides/source/rails_on_rack.md index d144fba762..b1a7865d10 100644 --- a/guides/source/rails_on_rack.md +++ b/guides/source/rails_on_rack.md @@ -326,7 +326,7 @@ The following shows how to replace use `Rack::Builder` instead of the Rails supp config.middleware.clear ``` -<br /> +<br> <strong>Add a `config.ru` file to `Rails.root`</strong> ```ruby diff --git a/guides/source/upgrading_ruby_on_rails.md b/guides/source/upgrading_ruby_on_rails.md index e7e28e21a3..0f388d15c4 100644 --- a/guides/source/upgrading_ruby_on_rails.md +++ b/guides/source/upgrading_ruby_on_rails.md @@ -194,16 +194,6 @@ If you are relying on the ability for external applications or Javascript to be * Rails 4.0 encrypts the contents of cookie-based sessions if `secret_key_base` has been set. Rails 3.x signed, but did not encrypt, the contents of cookie-based session. Signed cookies are "secure" in that they are verified to have been generated by your app and are tamper-proof. However, the contents can be viewed by end users, and encrypting the contents eliminates this caveat/concern without a significant performance penalty. -As described above, existing signed cookies generated with Rails 3.x will be transparently upgraded if you leave your existing `secret_token` in place and add the new `secret_key_base`. - -```ruby - # config/initializers/secret_token.rb - Myapp::Application.config.secret_token = 'existing secret token' - Myapp::Application.config.secret_key_base = 'new secret key base' -``` - -The same caveats apply here, too. You should wait to set `secret_key_base` until you have 100% of your userbase on Rails 4.x and are reasonably sure you will not need to rollback to Rails 3.x. You should also take care to make sure you are not relying on the ability to decode signed cookies generated by your app in external applications or Javascript before upgrading. - Please read [Pull Request #9978](https://github.com/rails/rails/pull/9978) for details on the move to encrypted session cookies. * Rails 4.0 removed the `ActionController::Base.asset_path` option. Use the assets pipeline feature. |