> For the complete documentation index, see [llms.txt](https://certil-remy.gitbook.io/learn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://certil-remy.gitbook.io/learn/rails/untitled-9.md).
# Rails form\_tag
## Rails Forms
Welcome to the world of Rails forms, which give users the ability to submit data into form fields. This can be used for: creating new database records, building a contact form, integrating a search engine field, and pretty much every other aspect of the application that requires user input. When it comes to forms in Rails, you will discover that you will have the flexibility to utilize:
* Built-in form helper methods
* Plain HTML form elements
This lesson is going to begin by integrating HTML form elements and then slowly start refactoring the form using Rails methods. It would be very easy to integrate form helpers (and we could have our form working in a few minutes). However, fully understanding what Rails is doing behind the scenes is more important than getting the form working right away. We're going to build the system from the ground up. When we're finished, you should be able to understand all of the processes that are necessary in order to process forms in an application properly and securely.
**Note:** For the next few labs, we're not going to use mass assignment, we'll assign each attribute individually. For example, instead of `Student.create(params[:students]) we'll write Student.create(first_name: params[:first_name], last_name: params[:last_name])` and name our fields in the view files without the "student" preface. We'll discuss why in the upcoming reading on Strong Params.
## Rendering the Form View
Today we'll be giving the user the ability to create a new post in our BlogFlash application. Let's first create a Capybara spec to ensure that going to `posts/new` takes us to our form. If you think back to the [Rails URL Helpers lesson](https://learn.co/lessons/rails-url-helpers-readme), we know that we don't need to hard-code the route into our tests any longer. Let's use the standard RESTful convention of `new_post_path` for the route helper name:
```
# spec/features/post_spec.rb
require 'rails_helper'
describe 'new post' do
it 'ensures that the form route works with the /new action' do
visit new_post_path
expect(page.status_code).to eq(200)
end
end
```
As expected, this results in a failure saying that we don't have a `new_post_path` method, so let's create that in our `routes.rb` file:
```
resources :posts, only: [:index, :new]
```
Now it gives this failure: `The action 'new' could not be found for PostsController`. To correct this, let's add a `new` action in `PostsController`:
Lastly, it says we're missing a template. Let's create `app/views/posts/new.html.erb`. Now that our routing test is passing, let's add a matcher spec to ensure that the template is properly displaying HTML on the new post page:
```
# spec/features/post_spec.rb
require 'rails_helper'
describe 'new post' do
...
it 'renders HTML in the /new template' do
visit new_post_path
expect(page).to have_content('Post Form')
end
end
```
Running this spec gets a matcher error. We can get this passing by adding `Post Form
` to the `new.html.erb` view template.
## Building the form in HTML
Our first pass at the form will be in plain HTML. In this reading, we're not concerned with creating any records in the database. Our focus is on the form process. We'll simply be printing out the submitted form params on the show page.
Let's create a spec for this. It's going to take a while for this to pass since we're going to be spending some time on the HTML creation process, but it's a good practice to ensure all new features are tested before the implementation code is added.
As you are updating the code, make sure to test it out in the browser – don't just rely on the tests. It's important to see the errors in both the tests and the browser since you'll want to become familiar with both types of failure messages.
```
# spec/features/post_spec.rb
require 'rails_helper'
describe 'new post' do
...
it "displays a new post form that redirects to the index page, which then contains the submitted post's title and description" do
visit new_post_path
fill_in 'post_title', with: 'My post title'
fill_in 'post_description', with: 'My post description'
click_on 'Submit Post'
expect(page.current_path).to eq(posts_path)
expect(page).to have_content('My post title')
expect(page).to have_content('My post description')
end
end
```
This fails for obvious reasons. Let's follow the TDD process, letting the failures help build our form. The first error says that Capybara can't find the form field `post_title`. To fix that, let's create an HTML form in the `new.html.erb` view template:
```
<%= params.inspect %>
```
The `name` attributes in each `input` should look pretty familiar by now –– they're good ole' nested hashes. Just like Sinatra, Rails takes the user input entered into form fields and stores it in the `params` hash. The `name` attribute for a given `input` field is used as the key within `params` at which the entered data is stored. For instance, the input entered into the "Post title:" field in the above form would be stored as the value of `params[:post][:title]`. Traditionally, Rails apps use that `model[attribute]` syntax for `name` attributes (e.g., `post[title]`). We'll talk more about that in a later lesson.
You'll also notice that we're printing out `params` to the page. Until we set up the form action, clicking `Submit Post` won't actually redirect to a page on which the input values will be visible, but we'd still like to verify that the `params` hash is being populated correctly.
If we run the tests again, we'll see that Capybara expected submitting the form to redirect it to `/posts`, but instead it found itself back on `/posts/new`. Capybara was able to fill in the form elements and click `Submit Post`, but we need to update the form tag with an `action` attribute:
```