Articles
-
<% @articles.each do |article| %>
- <%= article.title %> <% end %>
<%= @article.title %>
<%= @article.body %>
``` Now we can see the article when we visitArticles
-
<% @articles.each do |article| %>
- <%= article.title %> <% end %>
Articles
-
<% @articles.each do |article| %>
- <%= article.title %> <% end %>
Articles
-
<% @articles.each do |article| %>
- <%= link_to article.title, article %> <% end %>
New Article
<%= form_with model: @article do |form| %>
<%= form.label :title %>
<%= form.text_field :title %>
<%= form.text_field :title %>
<%= form.label :body %>
<%= form.text_area :body %>
<%= form.text_area :body %>
<%= form.submit %>
<% end %>
```
The [`form_with`](https://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-form_with)
helper method instantiates a form builder. In the `form_with` block we call
methods like [`label`](https://api.rubyonrails.org/classes/ActionView/Helpers/FormBuilder.html#method-i-label)
and [`text_field`](https://api.rubyonrails.org/classes/ActionView/Helpers/FormBuilder.html#method-i-text_field)
on the form builder to output the appropriate form elements.
The resulting output from our `form_with` call will look like:
```html
```
TIP: To learn more about form builders, see [Action View Form Helpers](
form_helpers.html).
#### Using Strong Parameters
Submitted form data is put into the `params` Hash, alongside captured route
parameters. Thus, the `create` action can access the submitted title via
`params[:article][:title]` and the submitted body via `params[:article][:body]`.
We could pass these values individually to `Article.new`, but that would be
verbose and possibly error-prone. And it would become worse as we add more
fields.
Instead, we will pass a single Hash that contains the values. However, we must
still specify what values are allowed in that Hash. Otherwise, a malicious user
could potentially submit extra form fields and overwrite private data. In fact,
if we pass the unfiltered `params[:article]` Hash directly to `Article.new`,
Rails will raise a `ForbiddenAttributesError` to alert us about the problem.
So we will use a feature of Rails called *Strong Parameters* to filter `params`.
Think of it as [strong typing](https://en.wikipedia.org/wiki/Strong_and_weak_typing)
for `params`.
Let's add a private method to the bottom of `app/controllers/articles_controller.rb`
named `article_params` that filters `params`. And let's change `create` to use
it:
```ruby
class ArticlesController < ApplicationController
def index
@articles = Article.all
end
def show
@article = Article.find(params[:id])
end
def new
@article = Article.new
end
def create
@article = Article.new(article_params)
if @article.save
redirect_to @article
else
render :new, status: :unprocessable_entity
end
end
private
def article_params
params.require(:article).permit(:title, :body)
end
end
```
TIP: To learn more about Strong Parameters, see [Action Controller Overview §
Strong Parameters](action_controller_overview.html#strong-parameters).
#### Validations and Displaying Error Messages
As we have seen, creating a resource is a multi-step process. Handling invalid
user input is another step of that process. Rails provides a feature called
*validations* to help us deal with invalid user input. Validations are rules
that are checked before a model object is saved. If any of the checks fail, the
save will be aborted, and appropriate error messages will be added to the
`errors` attribute of the model object.
Let's add some validations to our model in `app/models/article.rb`:
```ruby
class Article < ApplicationRecord
validates :title, presence: true
validates :body, presence: true, length: { minimum: 10 }
end
```
The first validation declares that a `title` value must be present. Because
`title` is a string, this means that the `title` value must contain at least one
non-whitespace character.
The second validation declares that a `body` value must also be present.
Additionally, it declares that the `body` value must be at least 10 characters
long.
NOTE: You may be wondering where the `title` and `body` attributes are defined.
Active Record automatically defines model attributes for every table column, so
you don't have to declare those attributes in your model file.
With our validations in place, let's modify `app/views/articles/new.html.erb` to
display any error messages for `title` and `body`:
```html+erb
New Article
<%= form_with model: @article do |form| %>
<%= form.label :title %>
<%= form.text_field :title %> <% @article.errors.full_messages_for(:title).each do |message| %>
<%= form.text_field :title %> <% @article.errors.full_messages_for(:title).each do |message| %>
<%= message %>
<% end %>
<%= form.label :body %>
<%= form.text_area :body %>
<% @article.errors.full_messages_for(:body).each do |message| %>
<%= form.text_area :body %>
<% @article.errors.full_messages_for(:body).each do |message| %>
<%= message %>
<% end %>
<%= form.submit %>
<% end %>
```
The [`full_messages_for`](https://api.rubyonrails.org/classes/ActiveModel/Errors.html#method-i-full_messages_for)
method returns an array of user-friendly error messages for a specified
attribute. If there are no errors for that attribute, the array will be empty.
To understand how all of this works together, let's take another look at the
`new` and `create` controller actions:
```ruby
def new
@article = Article.new
end
def create
@article = Article.new(article_params)
if @article.save
redirect_to @article
else
render :new, status: :unprocessable_entity
end
end
```
When we visit Articles
-
<% @articles.each do |article| %>
- <%= link_to article.title, article %> <% end %>
<%= form.label :title %>
<%= form.text_field :title %> <% article.errors.full_messages_for(:title).each do |message| %>
<%= form.text_field :title %> <% article.errors.full_messages_for(:title).each do |message| %>
<%= message %>
<% end %>
<%= form.label :body %>
<%= form.text_area :body %>
<% article.errors.full_messages_for(:body).each do |message| %>
<%= form.text_area :body %>
<% article.errors.full_messages_for(:body).each do |message| %>
<%= message %>
<% end %>
<%= form.submit %>
<% end %>
```
The above code is the same as our form in `app/views/articles/new.html.erb`,
except that all occurrences of `@article` have been replaced with `article`.
Because partials are shared code, it is best practice that they do not depend on
specific instance variables set by a controller action. Instead, we will pass
the article to the partial as a local variable.
Let's update `app/views/articles/new.html.erb` to use the partial via [`render`](
https://api.rubyonrails.org/classes/ActionView/Helpers/RenderingHelper.html#method-i-render):
```html+erb
New Article
<%= render "form", article: @article %> ``` NOTE: A partial's filename must be prefixed **with** an underscore, e.g. `_form.html.erb`. But when rendering, it is referenced **without** the underscore, e.g. `render "form"`. And now, let's create a very similar `app/views/articles/edit.html.erb`: ```html+erbEdit Article
<%= render "form", article: @article %> ``` TIP: To learn more about partials, see [Layouts and Rendering in Rails § Using Partials](layouts_and_rendering.html#using-partials). #### Finishing Up We can now update an article by visiting its edit page, e.g.<%= @article.title %>
<%= @article.body %>
- <%= link_to "Edit", edit_article_path(@article) %>
<%= @article.title %>
<%= @article.body %>
- <%= link_to "Edit", edit_article_path(@article) %>
- <%= link_to "Destroy", article_path(@article), data: { turbo_method: :delete, turbo_confirm: "Are you sure?" } %>
<%= @article.title %>
<%= @article.body %>
- <%= link_to "Edit", edit_article_path(@article) %>
- <%= link_to "Destroy", article_path(@article), data: { turbo_method: :delete, turbo_confirm: "Are you sure?" } %>
Add a comment:
<%= form_with model: [ @article, @article.comments.build ] do |form| %>
<%= form.label :commenter %>
<%= form.text_field :commenter %>
<%= form.label :body %>
<%= form.text_area :body %>
<%= form.submit %>
<% end %> ``` This adds a form on the `Article` show page that creates a new comment by calling the `CommentsController` `create` action. The `form_with` call here uses an array, which will build a nested route, such as `/articles/1/comments`. Let's wire up the `create` in `app/controllers/comments_controller.rb`: ```ruby class CommentsController < ApplicationController def create @article = Article.find(params[:article_id]) @comment = @article.comments.create(comment_params) redirect_to article_path(@article) end private def comment_params params.require(:comment).permit(:commenter, :body) end end ``` You'll see a bit more complexity here than you did in the controller for articles. That's a side-effect of the nesting that you've set up. Each request for a comment has to keep track of the article to which the comment is attached, thus the initial call to the `find` method of the `Article` model to get the article in question. In addition, the code takes advantage of some of the methods available for an association. We use the `create` method on `@article.comments` to create and save the comment. This will automatically link the comment so that it belongs to that particular article. Once we have made the new comment, we send the user back to the original article using the `article_path(@article)` helper. As we have already seen, this calls the `show` action of the `ArticlesController` which in turn renders the `show.html.erb` template. This is where we want the comment to show, so let's add that to the `app/views/articles/show.html.erb`. ```html+erb<%= @article.title %>
<%= @article.body %>
- <%= link_to "Edit", edit_article_path(@article) %>
- <%= link_to "Destroy", article_path(@article), data: { turbo_method: :delete, turbo_confirm: "Are you sure?" } %>
Comments
<% @article.comments.each do |comment| %>Commenter: <%= comment.commenter %>
Comment: <%= comment.body %>
<% end %>Add a comment:
<%= form_with model: [ @article, @article.comments.build ] do |form| %>
<%= form.label :commenter %>
<%= form.text_field :commenter %>
<%= form.label :body %>
<%= form.text_area :body %>
<%= form.submit %>
<% end %> ``` Now you can add articles and comments to your blog and have them show up in the right places.  Refactoring ----------- Now that we have articles and comments working, take a look at the `app/views/articles/show.html.erb` template. It is getting long and awkward. We can use partials to clean it up. ### Rendering Partial Collections First, we will make a comment partial to extract showing all the comments for the article. Create the file `app/views/comments/_comment.html.erb` and put the following into it: ```html+erbCommenter: <%= comment.commenter %>
Comment: <%= comment.body %>
``` Then you can change `app/views/articles/show.html.erb` to look like the following: ```html+erb<%= @article.title %>
<%= @article.body %>
- <%= link_to "Edit", edit_article_path(@article) %>
- <%= link_to "Destroy", article_path(@article), data: { turbo_method: :delete, turbo_confirm: "Are you sure?" } %>
Comments
<%= render @article.comments %>Add a comment:
<%= form_with model: [ @article, @article.comments.build ] do |form| %>
<%= form.label :commenter %>
<%= form.text_field :commenter %>
<%= form.label :body %>
<%= form.text_area :body %>
<%= form.submit %>
<% end %> ``` This will now render the partial in `app/views/comments/_comment.html.erb` once for each comment that is in the `@article.comments` collection. As the `render` method iterates over the `@article.comments` collection, it assigns each comment to a local variable named the same as the partial, in this case `comment`, which is then available in the partial for us to show. ### Rendering a Partial Form Let us also move that new comment section out to its own partial. Again, you create a file `app/views/comments/_form.html.erb` containing: ```html+erb <%= form_with model: [ @article, @article.comments.build ] do |form| %>
<%= form.label :commenter %>
<%= form.text_field :commenter %>
<%= form.label :body %>
<%= form.text_area :body %>
<%= form.submit %>
<% end %> ``` Then you make the `app/views/articles/show.html.erb` look like the following: ```html+erb<%= @article.title %>
<%= @article.body %>
- <%= link_to "Edit", edit_article_path(@article) %>
- <%= link_to "Destroy", article_path(@article), data: { turbo_method: :delete, turbo_confirm: "Are you sure?" } %>
Comments
<%= render @article.comments %>Add a comment:
<%= render 'comments/form' %> ``` The second render just defines the partial template we want to render, `comments/form`. Rails is smart enough to spot the forward slash in that string and realize that you want to render the `_form.html.erb` file in the `app/views/comments` directory. The `@article` object is available to any partials rendered in the view because we defined it as an instance variable. ### Using Concerns Concerns are a way to make large controllers or models easier to understand and manage. This also has the advantage of reusability when multiple models (or controllers) share the same concerns. Concerns are implemented using modules that contain methods representing a well-defined slice of the functionality that a model or controller is responsible for. In other languages, modules are often known as mixins. You can use concerns in your controller or model the same way you would use any module. When you first created your app with `rails new blog`, two folders were created within `app/` along with the rest: ``` app/controllers/concerns app/models/concerns ``` A given blog article might have various statuses - for instance, it might be visible to everyone (i.e. `public`), or only visible to the author (i.e. `private`). It may also be hidden to all but still retrievable (i.e. `archived`). Comments may similarly be hidden or visible. This could be represented using a `status` column in each model. First, let's run the following migrations to add `status` to `Articles` and `Comments`: ```bash $ bin/rails generate migration AddStatusToArticles status:string $ bin/rails generate migration AddStatusToComments status:string ``` And next, let's update the database with the generated migrations: ```bash $ bin/rails db:migrate ``` TIP: To learn more about migrations, see [Active Record Migrations]( active_record_migrations.html). We also have to permit the `:status` key as part of the strong parameter, in `app/controllers/articles_controller.rb`: ```ruby private def article_params params.require(:article).permit(:title, :body, :status) end ``` and in `app/controllers/comments_controller.rb`: ```ruby private def comment_params params.require(:comment).permit(:commenter, :body, :status) end ``` Within the `article` model, after running a migration to add a `status` column using `bin/rails db:migrate` command, you would add: ```ruby class Article < ApplicationRecord has_many :comments validates :title, presence: true validates :body, presence: true, length: { minimum: 10 } VALID_STATUSES = ['public', 'private', 'archived'] validates :status, inclusion: { in: VALID_STATUSES } def archived? status == 'archived' end end ``` and in the `Comment` model: ```ruby class Comment < ApplicationRecord belongs_to :article VALID_STATUSES = ['public', 'private', 'archived'] validates :status, inclusion: { in: VALID_STATUSES } def archived? status == 'archived' end end ``` Then, in our `index` action template (`app/views/articles/index.html.erb`) we would use the `archived?` method to avoid displaying any article that is archived: ```html+erbArticles
-
<% @articles.each do |article| %>
<% unless article.archived? %>
- <%= link_to article.title, article %> <% end %> <% end %>
Commenter: <%= comment.commenter %>
Comment: <%= comment.body %>
<% end %> ``` However, if you look again at our models now, you can see that the logic is duplicated. If in the future we increase the functionality of our blog - to include private messages, for instance - we might find ourselves duplicating the logic yet again. This is where concerns come in handy. A concern is only responsible for a focused subset of the model's responsibility; the methods in our concern will all be related to the visibility of a model. Let's call our new concern (module) `Visible`. We can create a new file inside `app/models/concerns` called `visible.rb` , and store all of the status methods that were duplicated in the models. `app/models/concerns/visible.rb` ```ruby module Visible def archived? status == 'archived' end end ``` We can add our status validation to the concern, but this is slightly more complex as validations are methods called at the class level. The `ActiveSupport::Concern` ([API Guide](https://api.rubyonrails.org/classes/ActiveSupport/Concern.html)) gives us a simpler way to include them: ```ruby module Visible extend ActiveSupport::Concern VALID_STATUSES = ['public', 'private', 'archived'] included do validates :status, inclusion: { in: VALID_STATUSES } end def archived? status == 'archived' end end ``` Now, we can remove the duplicated logic from each model and instead include our new `Visible` module: In `app/models/article.rb`: ```ruby class Article < ApplicationRecord include Visible has_many :comments validates :title, presence: true validates :body, presence: true, length: { minimum: 10 } end ``` and in `app/models/comment.rb`: ```ruby class Comment < ApplicationRecord include Visible belongs_to :article end ``` Class methods can also be added to concerns. If we want to display a count of public articles or comments on our main page, we might add a class method to Visible as follows: ```ruby module Visible extend ActiveSupport::Concern VALID_STATUSES = ['public', 'private', 'archived'] included do validates :status, inclusion: { in: VALID_STATUSES } end class_methods do def public_count where(status: 'public').count end end def archived? status == 'archived' end end ``` Then in the view, you can call it like any class method: ```html+erbArticles
Our blog has <%= Article.public_count %> articles and counting!-
<% @articles.each do |article| %>
<% unless article.archived? %>
- <%= link_to article.title, article %> <% end %> <% end %>
<%= form.label :status %>
<%= form.select :status, ['public', 'private', 'archived'], selected: 'public' %>
```
and in `app/views/comments/_form.html.erb`:
```html+erb
<%= form.select :status, ['public', 'private', 'archived'], selected: 'public' %>
<%= form.label :status %>
<%= form.select :status, ['public', 'private', 'archived'], selected: 'public' %>
Commenter: <%= comment.commenter %>
Comment: <%= comment.body %>
<%= link_to "Destroy Comment", [comment.article, comment], data: { turbo_method: :delete, turbo_confirm: "Are you sure?" } %>
``` Clicking this new "Destroy Comment" link will fire off a `DELETE /articles/:article_id/comments/:id` to our `CommentsController`, which can then use this to find the comment we want to delete, so let's add a `destroy` action to our controller (`app/controllers/comments_controller.rb`): ```ruby class CommentsController < ApplicationController def create @article = Article.find(params[:article_id]) @comment = @article.comments.create(comment_params) redirect_to article_path(@article) end def destroy @article = Article.find(params[:article_id]) @comment = @article.comments.find(params[:id]) @comment.destroy redirect_to article_path(@article), status: 303 end private def comment_params params.require(:comment).permit(:commenter, :body, :status) end end ``` The `destroy` action will find the article we are looking at, locate the comment within the `@article.comments` collection, and then remove it from the database and send us back to the show action for the article. ### Deleting Associated Objects If you delete an article, its associated comments will also need to be deleted, otherwise they would simply occupy space in the database. Rails allows you to use the `dependent` option of an association to achieve this. Modify the Article model, `app/models/article.rb`, as follows: ```ruby class Article < ApplicationRecord include Visible has_many :comments, dependent: :destroy validates :title, presence: true validates :body, presence: true, length: { minimum: 10 } end ``` Security -------- ### Basic Authentication If you were to publish your blog online, anyone would be able to add, edit and delete articles or delete comments. Rails provides an HTTP authentication system that will work nicely in this situation. In the `ArticlesController` we need to have a way to block access to the various actions if the person is not authenticated. Here we can use the Rails `http_basic_authenticate_with` method, which allows access to the requested action if that method allows it. To use the authentication system, we specify it at the top of our `ArticlesController` in `app/controllers/articles_controller.rb`. In our case, we want the user to be authenticated on every action except `index` and `show`, so we write that: ```ruby class ArticlesController < ApplicationController http_basic_authenticate_with name: "dhh", password: "secret", except: [:index, :show] def index @articles = Article.all end # snippet for brevity ``` We also want to allow only authenticated users to delete comments, so in the `CommentsController` (`app/controllers/comments_controller.rb`) we write: ```ruby class CommentsController < ApplicationController http_basic_authenticate_with name: "dhh", password: "secret", only: :destroy def create @article = Article.find(params[:article_id]) # ... end # snippet for brevity ``` Now if you try to create a new article, you will be greeted with a basic HTTP Authentication challenge:  Other authentication methods are available for Rails applications. Two popular authentication add-ons for Rails are the [Devise](https://github.com/plataformatec/devise) rails engine and the [Authlogic](https://github.com/binarylogic/authlogic) gem, along with a number of others. ### Other Security Considerations Security, especially in web applications, is a broad and detailed area. Security in your Rails application is covered in more depth in the [Ruby on Rails Security Guide](security.html). What's Next? ------------ Now that you've seen your first Rails application, you should feel free to update it and experiment on your own. Remember, you don't have to do everything without help. As you need assistance getting up and running with Rails, feel free to consult these support resources: * The [Ruby on Rails Guides](index.html) * The [Ruby on Rails mailing list](https://discuss.rubyonrails.org/c/rubyonrails-talk) * The [#rubyonrails](irc://irc.freenode.net/#rubyonrails) channel on irc.freenode.net Configuration Gotchas --------------------- The easiest way to work with Rails is to store all external data as UTF-8. If you don't, Ruby libraries and Rails will often be able to convert your native data into UTF-8, but this doesn't always work reliably, so you're better off ensuring that all external data is UTF-8. If you have made a mistake in this area, the most common symptom is a black diamond with a question mark inside appearing in the browser. Another common symptom is characters like "ü" appearing instead of "ü". Rails takes a number of internal steps to mitigate common causes of these problems that can be automatically detected and corrected. However, if you have external data that is not stored as UTF-8, it can occasionally result in these kinds of issues that cannot be automatically detected by Rails and corrected. Two very common sources of data that are not UTF-8: * Your text editor: Most text editors (such as TextMate), default to saving files as UTF-8. If your text editor does not, this can result in special characters that you enter in your templates (such as é) to appear as a diamond with a question mark inside in the browser. This also applies to your i18n translation files. Most editors that do not already default to UTF-8 (such as some versions of Dreamweaver) offer a way to change the default to UTF-8. Do so. * Your database: Rails defaults to converting data from your database into UTF-8 at the boundary. However, if your database is not using UTF-8 internally, it may not be able to store all characters that your users enter. For instance, if your database is using Latin-1 internally, and your user enters a Russian, Hebrew, or Japanese character, the data will be lost forever once it enters the database. If possible, use UTF-8 as the internal storage of your database.