• Build forms that allow a user to create and edit a given resource and its associated resources.
• Build controller actions that handle the requests sent by such forms.

As the relationships we build between our models grow and become more complex, we need to build ways for our users to interact with those models in all of their complexity. If a genre has many songs, then a user should be able to create a new song and select from a list of existing genres and/or create a new genre to be associated with that song, all at the same time. In other words, if our models are associated in a certain way, our users should be able to create and edit instances of those models in ways that reflect those associations.

In order to achieve this, we'll have to build forms that allow for a user to create and edit not just the given object but any and all objects that are associated with it.

This is a walk-through with some extra challenges for you to complete on your own. There are tests, so be sure to run the tests to make sure you're following along correctly. To follow along, use shotgun to start your app and visit URLs/fill out forms as instructed. In this walk-through, we're dealing with a pet domain model. We have an Owner model and a Pet model. An owner has many pets, and a pet belongs to an owner. We've already built the migrations, models, and some controller actions and views. Fork and clone this lab to follow along.

Because an owner can have many pets, we want to be able to choose which of the existing pets in our database to associate to a new owner when the owner is being created. We also want to be able to create a new pet and associate it with the owner being created. So, our form for a new owner must contain a way to select a number of existing pets to associate with that owner as well as a way to create a brand new pet to associate with that owner. The same is true of editing a given owner: we should be able to select and deselect existing pets and/or create a new pet to associate with the owner.

Here, we'll be taking a look together at the code that will implement this functionality. Then, you'll build out the same feature for creating/editing new pets.

Since we've provided you with much of the code for this project, take a few moments to go through the provided files and familiarize yourself with the app. Note that an owner has a name and has many pets and a pet has a name and belongs to an owner. Note that we have two separate controllers, one for pets and one for owners, each of which inherit from the main application controller. Note that each controller has a set of routes that enable the basic CRUD actions (except for delete –– we don't really care about deleting for the purposes of this exercise).

Make sure you run rake db:migrate and rake db:seed before you move on. This will migrate our database and seed it with one owner and two pets to get us started.

The phrase 'seeding the database' refers to the practice of filling up your database with some dummy data. As we develop our apps, it is essential that we have some data to work with. Otherwise, we won't be able to tell if our app is working or try out the actions and features that we are building. Sinatra makes it easy for us to seed our database by providing us with something called a seed file. This file should be placed in the db directory, db/seeds.rb. The seed file is where you can write code that creates and saves instances of your models.

When you run the seed task provided by Sinatra and Rake, rake db:seed, the code in the seed file will be executed, inserting some sample data into your database.

Go ahead and open up the seed file in this app, db/seeds.rb. You should see the following:

# Add seed data here. Seed your database with `rake db:seed`
sophie = Owner.create(name: "Sophie")
Pet.create(name: "Maddy", owner: sophie)
Pet.create(name: "Nona", owner: sophie)

This is code you should be pretty familiar with by now. We are simply creating and saving an instance of our Owner class and creating and saving two new instances of the Pet class.

So, when rake db:seed is run, the code in this file is actually executed, inserting the data regarding Sophie, Maddy, and Nona into our database.

You can write code to seed your database in any number of ways. We've done it fairly simply here, but you could imagine writing code in your seed file that sends a request to an external API and instantiates and saves instances of a class using the response from the API. You could also write code that opens a directory of files and uses information about each file to create and save instances of a class. The list goes on.

Open up app/views/owners/new.erb and you should see the following code:

<h1>Create a new Owner</h1>

<form action="/owners" method="POST">
  <label>Name:</label>

  <br>

  <input type="text" name="owner[name]" id="owner_name">

  <input type="submit" value="Create Owner">
</form>

Here we have a basic form for a new owner with a field for that new owner's name. However, we want our users to be able to create an owner and select existing pets to associate with that new owner at the same time. So, our form should include a list of checkboxes, one for each existing pet, for our user to select from at will.

How can we dynamically, or programmatically, generate a list of checkboxes for all of the pets that are currently in our database?

In order to dynamically generate these checkboxes, we need to load up all of the pets from the database. Then, we can iterate over them in our owners/new.erb view using ERB tags to inject each pet's information into a checkbox form element. Let's take a look:

# controllers/owners_controller.rb
get '/owners/new' do
  @pets = Pet.all
  erb :'/owners/new'
end

# views/owners/new.erb
<% @pets.each do |pet| %>
  <input type="checkbox" name="owner[pet_ids][]" id="<%= pet.id %>" value="<%= pet.id %>"><%= pet.name %><br>
<% end %>

Let's break this down:

• We use ERB to get all of the pets with Pet.all, then we iterate over that collection of Pet objects and generate a checkbox for each pet.

• That checkbox has a name of "owner[pet_ids][]" because we want to structure our params hash such that the array of pet IDs is stored inside the "owner" hash. We are aiming to associate the pets that have these IDs with the new owner.

• We give the checkbox a value of the given pet's ID. This way, when that checkbox is selected, its value, i.e., the pet's ID, is what gets sent through to the params hash.

• We give the checkbox an id of the given pet's ID so that our Capybara test can find the checkbox using the pet's ID.

• Finally, in between the opening and closing input tags, we use ERB to render the given pet's name.

The result is a form that looks something like this:

Let's place a binding.pry in the post '/owners' route and submit our form so that we can get a better understanding of the params hash we're creating with our form. Once you hit your binding, type params in the terminal, and you should see something like this:

{"owner"=>{"name"=>"Adele", "pet_ids"=>["1", "2"]}}

I filled out my form with a name of "Adele", and I checked the boxes for "Maddy" and "Nona". So, our params hash has a key of "owner" that points to a value that is a hash containing two keys: "name", with a value of the name entered into the form, and "pet_ids", with a value of an array containing the ids of all of the pets we selected via our checkboxes. Let's move on to writing the code that will create a new owner and associate it to these pets.

We are familiar with using mass assignment to create new instances of a class with Active Record. For example, if we had a hash, owner_info, that looked like this...

owner_info = {name: "Adele"}

...we could easily create a new owner like this:

Owner.create(owner_info)

But our params hash contains this additional key of "pet_ids" pointing to an array of pet ID numbers. You may be wondering if we can still use mass assignment here. Well, the answer is yes. Active Record is smart enough to take that key of pet_ids, pointing to an array of numbers, find the pets that have those IDs, and associate them to the given owner, all because we set up our associations such that an owner has many pets. Wow! Let's give it a shot. Still in your Pry console that you entered via the binding.pry in the post '/owners' action of the OwnersController, type:

@owner = Owner.create(params["owner"])
# => #<Owner:0x007fdfcc96e430 id: 2, name: "Adele">

It worked! Now, type:

@owner.pets
#=> [#<Pet:0x007fb371bc22b8 id: 1, name: "Maddy", owner_id: 2>, #<Pet:0x007fb371bc1f98 id: 2, name: "Nona", owner_id: 2>]

And our usage of mass assignment successfully associated the new owner with the pets whose ID numbers were in the params hash!

Now that we have this working code, let's go ahead and place it in our post '/owners' action:

# app/controllers/owners_controller.rb

post '/owners' do
  @owner = Owner.create(params[:owner])
  redirect "/owners/#{@owner.id}"
end

Great! We're almost done with this feature. But, remember that we want a user to be able to create a new owner, select some existing pets to associate with that owner, and also have the option of creating a new pet to associate with that owner. Let's build that latter capability into our form.

This will be fairly simple. All we need to do is add a section to our form for creating a new pet:

and/or, create a new pet:
    <br>
    <label>name:</label>
      <input  type="text" name="pet[name]"></input>
    <br>

Now our whole form should look something like this:

<h1>Create a New Owner</h1>

<form action="/owners" method="POST">
  <label>Owner Name:</label>
  <br>
  <input type="text" name="owner[name]">

  <br>
  <p>Select an existing pet or create a new one below.</p>


  <h3>Existing Pets</h3>
  <% @pets.each do |pet| %>
    <input type="checkbox" name="owner[pet_ids][]" id="<%= pet.id %>" value="<%= pet.id %>"><%= pet.name %></input><br>
  <% end %>
  <br>

  <h3>New Pet</h3>
  <label>Pet Name: </label>
  <br>
  <input type="text" name="pet[name]" id="pet_name"></input>
  <br><br>

  <input type="submit" value="Create Owner">
</form>

Note that we've included the section for creating a new pet at the bottom of the form and we've given that input field a name of pet[name]. Now, if we fill out our form like this...

...when we submit our form, our params hash should look something like this:

{"owner"=>{"name"=>"Adele", "pet_ids"=>["1", "2"]}, "pet"=>{"name"=>"Fake Pet"}}

Our params["owner"] hash is unchanged, so @owner = Owner.create(params["owner"]) still works. But what about creating our new pet with a name of "Fake Pet" and associating it to our new owner?

For this, we'll have to grab the new pet's name from params["pet"]["name"], use it to create a new pet, and add the new pet to our new owner's collection of pets:

@owner.pets << Pet.create(name: params["pet"]["name"])

But, you might be wondering, what if the user does not fill out the field to name and create a new pet? In that case, our params hash would look like this:

{"owner"=>{"name"=>"Adele", "pet_ids"=>["1", "2"]}, "pet"=>{"name"=>""}}

The above line of code would create a new pet with a name of an empty string and associate it to our owner. That's no good. We'll need a way to control whether or not the above line of code runs. Let's create an if statement to check whether or not the value of params["pet"]["name"] is an empty string.

if !params["pet"]["name"].empty?
  @owner.pets << Pet.create(name: params["pet"]["name"])
end

That looks pretty good. Let's put it all together:

post '/owners' do
  @owner = Owner.create(params[:owner])
  if !params["pet"]["name"].empty?
    @owner.pets << Pet.create(name: params["pet"]["name"])
  end
  redirect "owners/#{@owner.id}"
end

NOTE: When using the shovel operator, ActiveRecord instantly fires update SQL without waiting for the save or update call on the parent object, unless the parent object is a new record.

Let's sum up before we move on. We:

• Built a form that dynamically generates checkboxes for each of the existing pets.

• Added a field to that form in which a user can fill out the name for a brand new pet.

• Built a controller action that uses mass assignment to create a new owner and associate it to any existing pets that the user selected via checkboxes.

• Added to that controller action code that checks to see if a user did in fact fill out the form field to name and create a new pet. If so, our code will create that new pet and add it to the newly-created owner's collection of pets.

Now that we can create a new owner with associated pets, let's build out the feature for editing that owner and their associated pets.

Our edit form will be very similar to our create form. We want a user to be able to edit everything about an owner: the owner's name, any existing pet associations, and any new pet the user would like to create and associate with that owner. So, our form should have the standard, pre-filled name field as well as dynamically generated checkboxes for existing pets. This time, though, the checkboxes should be automatically checked if the given owner already owns that pet. Finally, we'll need the same form field we built earlier for a user to create a new pet to be associated with our owner.

Let's do it!

# edit.erb
<h1>Update Owner</h1>

<h2>Edits for <%= @owner.name %></h2>

  <form action="/owners/<%= @owner.id %>" method="POST">
    <input id="hidden" type="hidden" name="_method" value="patch">
    <label>Edit the Owner's Name:</label>
    <br>
    <input type="text" name="owner[name]" value="<%= @owner.name %>">

    <br>
    <p>Select an existing pet or create a new one below.</p>


    <h3>Existing Pets</h3>
    <% @pets.each do |pet| %>
      <input type="checkbox" name="owner[pet_ids][]" id="<%= pet.id %>" value="<%= pet.id %>" <%='checked' if @owner.pets.include?(pet) %>><%= pet.name %></input><br>
    <% end %>
    <br>

    <h3>New Pet</h3>
    <label>Pet Name: </label>
    <br>
    <input type="text" name="pet[name]" id="pet_name"></input>
    <br><br>

    <input type="submit" value="Update Owner">
  </form>

The main difference here is that we added the checked property to each checkbox with a condition to test whether the given pet is already present in the current owner's collection of pets. We implemented this if statement by wrapping the checked attribute in ERB tags, allowing us to use Ruby on our view page.

Go ahead and make some changes to your owner using this edit form, then place a binding.pry in your patch '/owners/:id' action and submit the form. Once you hit your binding, type params in the terminal.

I filled out my edit form like this:

Notice that I've unchecked the first two pets, Maddy and Nona, and checked the next two pets.

My params hash consequently looks like this:

{"owner"=>{"name"=>"Adele", "pet_ids"=>["3", "4"]},
 "pet"=>{"name"=>"Another New Pet"},
 "splat"=>[],
 "captures"=>["8"],
 "id"=>"8"}

Let's update our owner with this new information. Just as Active Record was smart enough to allow us to use mass assignment to not only create a new owner but to associate that owner to the pets whose IDs were contained in the "pet_ids" array, it is also smart enough to allow us to update an owner in the same way. In our Pry console in the terminal, let's execute the following:

@owner = Owner.find(params[:id])
@owner.update(params[:owner])

Now, if we type @owner.pets, we'll see that the owner is no longer associated to the pets with an ID of 1 or 2, but they are associated to pets 3 and 4:

@owner.pets
# => [#<Pet:0x007fd511d5e560 id: 3, name: "SBC", owner_id: 8>,
 #<Pet:0x007fd511d5e3d0 id: 4, name: "Fake Pet", owner_id: 8>]

Great! Now, we need to implement logic similar to that in our post '/owners' action to handle a user trying to associate a brand new pet to our owner:

patch '/owners/:id' do
    ####### bug fix
    if !params[:owner].keys.include?("pet_ids")
    params[:owner]["pet_ids"] = []
    end
    #######

    @owner = Owner.find(params[:id])
    @owner.update(params["owner"])
    if !params["pet"]["name"].empty?
      @owner.pets << Pet.create(name: params["pet"]["name"])
    end
    redirect "owners/#{@owner.id}"
end

NOTE: The bug fix is required so that it's possible to remove ALL previous pets from owner.

And that's it!

Now that we've walked through these features together for the Owner model, take some time and try to build out the same functionality for Pet. The form to create a new pet should allow a user to select from the list of available owners and/or create a new owner, and the form to edit a given pet should allow the user to select a new owner or create a new owner. Note that if a new owner is created it would override any existing owner that is selected.

Make sure you run the tests to check your work.