Learn how to take some of those advanced querying concepts you used in SQL and have Rails do them for you.

Introduction

Up until now, we’ve covered the bread and butter you need to build basic queries using Active Record. After building a handful of projects and working through the tutorial, you should be comfortable making these queries.

Active Record is much more powerful than just simple CRUD actions on individual records. It gives you a Ruby-ish interface to do almost anything you can do with bare-metal SQL statements. You can cherry-pick individual groups of records based on specific criteria and order them however you want. You can join tables manually or query using associations set up by Rails. You can return lists of records or perform basic math like counts and averages.

All this is done at the database level, which is much faster than loading up a whole table of stuff into Ruby objects before parsing and chopping and calculating with it.

In this lesson, we’ll get into the more interesting and useful areas of Active Record queries. You’ll learn what Active Record actually returns and how to manipulate the returned values at will. You’ll also learn how to make your queries more efficient along the way.

There’s a lot of material to read and cover, but it basically follows the idea “anything you can do in SQL, you can do in Active Record”. They mostly use the same terminology as well. Active Record just extends that functionality by giving you a suite of versatile methods (and concepts like Relations) to make it much more user-friendly along the way.

You Should Understand

1. What is an ActiveRecord::Relation?
2. What does Lazy Evaluation mean?
3. How do you make a relation evaluate into an array?
4. How do you check whether a database already contains a record?
5. Why is #find_by useful and how is it used?
6. What’s the difference between what’s returned using a #where query and a #find query?
7. How do you join tables together in Rails?
8. When can you use symbols / hashes and when do you need to use explicit strings for query parameters?
9. What are Scopes and why are they useful?
10. What needs to happen for a class method to act like a scope?

 Relations and Lazy Evaluation

Using User.find(1) will return an unambiguous object — it’s going to find the user with ID = 1 and give it to you as a Ruby object. But this behavior is actually unusual. Most queries don’t actually return a Ruby object, they just fake it. For example:

    User.where(:id => 1)

Might look like it returns an array that contains a serialized User object, like:

    [#<User id: 1, email: "foo@bar.com">]

But try running User.where(:id => 1).class and you’ll see that it isn’t an Array, it’s actually an instance of ActiveRecord::Relation. Relations are actually just really good at looking like arrays but they’ve got more going on.

Active Record queries return relations to be lazy. There’s basically no reason to actually tell the database to execute a query until the very last possible minute. What if you never actually needed to use that query at all? What if you want to make it more complex before executing it? Relations give you that flexibility and make much more efficient use of your database’s valuable time.

Relations only get executed when it becomes absolutely necessary to know what’s inside them. So if your controller grabs 5 blog posts using @posts = Post.limit(5), that is really passing your view a relation. It’s only when the code in the view actually calls a method on @posts (like @posts.first.title) that the query will be run and the relation will get stored as a real Ruby object in memory.

This behavior can be a bit tricky to observe if you use something like the Rails Console ($ rails console) to test them out, because the queries will actually be run right away in the console since it implicitly runs something like the .inspect method on the relation, which requires the query to be run. But try playing with building a query like we did above and checking out its #class… you’ll usually get back ActiveRecord::Relation.

 Chaining Queries

Relations aren’t just built for speed… they’re also built for flexibility. Let’s say you want to grab the first 5 posts listed in ascending order (Post.limit(5).order(:created_at => :desc)). Because #limit returns a Relation, #order takes that relation and adds its own criteria to it. You can chain together a dozen methods this way, and, when it’s finally time to execute, ActiveRecord and SQL (if that’s what you’re using for the DB) will figure out the optimal way to structure the query to achieve the desired result.

This is the sort of behavior that you just sort of expect to work, and Relations are what enables it to do so.

 Why Care?

You should care that ActiveRecord queries usually return Relations because you’ll run into them often when coding and debugging. The knowledge should make you comfortable chaining query methods together to construct elaborate queries.

If you end up working with a Relation when you really want it to act like an Array, you can sometimes run #to_a on it to force it to evaluate the query.

A couple of common methods which do NOT return Relations and can force evaluation of a relation, are #all (returns an array of objects) and #find (returns a single object).

 Beyond Basic Querying

You should be confident now with simple queries like finding objects. The reading you do for this section will cover the basics and then dive in a bit further than before. There are a couple of new concepts worth mentioning.

 Checking for Existence

The simplest new concept is how to check whether an object actually exists yet or not, which you may want to do before running a method which depends on the object actually having been saved already.

#exists? will return true/false. #any? will be true if any records match the specified criteria and #many? will be true if multiple records match the specified criteria. You can run each of these either on a model directly, a Relation, an association, or a scope (which we’ll cover later). Basically, anywhere you might think of using them, they’re likely to work:

    # From the Guide:
    # via a model
    Post.any?
    Post.many?

    # via a relation
    Post.where(:published => true).any?
    Post.where(:published => true).many?

    # via an association
    Post.first.categories.any?
    Post.first.categories.many?

 Arguments

There are multiple ways to submit arguments for most Rails query methods. You can typically use either symbols or strings or both. I prefer to stick with symbols and hashes wherever possible. You can also use ? parameters like in normal SQL. When it’s not ambiguous (ie. if you aren’t working with multiple tables) you can also choose to specify the table name or not (see #5 below). All of the following are the same:

1. User.where(:email => "foo@bar.com")
2. User.where("email" => "foo@bar.com")
3. User.where("email = 'foo@bar.com'")
4. User.where("email = ?", "foo@bar.com")
5. User.where("users.email" => "foo@bar.com")

 More Assorted Querying Knowledge

Very large queries can actually be batched into lots of subqueries so they don’t eat up tons of performance resources. #find_each does the trick. The basic principle is that it chunks the query into pieces, loading up the first piece and evaluating it before moving onto the next one. This will be helpful for you when optimizing queries but isn’t really something to worry too much about up front.

#where queries give you a fair bit of flexibility. They let you specify an exact value to find, a range of values to find, or several values to find. If you know what type of query you’re looking for, you can almost guess the proper syntax for executing it.

The key thing to note is that #find returns the actual record while #where returns an ActiveRecord::Relation which basically acts like an array. So if you’re using #where to find a single record, you still need to remember to go into that “array” and grab the first record, e.g. User.where(:email => "foo@bar.com")[0] or User.where(:email => "foo@bar.com").first.

#find_by is a really neat method that basically lets you build your own finder method. It’s an alternative to using #where (to which you’d have to add another method like #take or #first to pull the result out of the returned array). If you want to find by a user’s email, write User.find_by(:email => 'foo@bar.com').

#select should be pretty obvious to a SQL ninja like you — it lets you choose which columns to select from the table(s), just like in SQL. To select just the ID column for all users, it’s as simple as User.select(:id). You can also use aliases like in SQL but should use quotes instead of symbols, e.g. @users = User.select("users.id AS user_id") will create a new attribute called user_id, e.g. allowing you to access @users.first.user_id.

 Aggregations

Just like with SQL, you often want to group fields together (or “roll up” the values under one header). For example, grouping blog posts written on a certain date. This is most useful when you also apply mathematical operations to them like #count or #max. An example (a bit more complex because it involves joining two tables) is if I want to get a count of all the blog posts categorized by each tag. I might write something like:

Post.joins(:tags).group("tags.name").count
# => {"tag1" => 4, "tag2" => 2, "tag3" => 5}

#having is sort of like a #where clause for grouped queries.

 Joins

When working with multiple tables, you’ll often want to join them together. Rails associations often do the heavy lifting of setting up the joins for you if you’re working with instances of an object, so you may not need to explicitly use a #join right away.

But if you’re running queries like in the Post-Tag-count grouping example used above, you’ll need to use joins to bring together the appropriate tables. You need to be more careful with how you select data when using joins — if you are looking for the :id column, which table’s ID are we asking for? You’ll find yourself using more explicit strings when joining, e.g. in the example above (copied below) where we specify the name attribute of the tags table:

Post.joins(:tags).group("tags.name").count
# => {"tag1" => 4, "tag2" => 2, "tag3" => 5}

 Your Tasks

1. Real Rails Guides Active Record Query Interface (http://guides.rubyonrails.org/active_record_querying.html). Read the first 5 sections for a more basic overview of query functions. Don’t worry too much about batching and #find_each.

2. Real Rails Guides Active Record Query Interface (http://guides.rubyonrails.org/active_record_querying.html). Read section 18  or a brief look at using exists?any? and many?.

3. Real Rails Guides Active Record Query Interface (http://guides.rubyonrails.org/active_record_querying.html). Read sections 6, 7 and 19 for an understanding of aggregate functions and the calculations you can run on them.

4. Real Rails Guides Active Record Query Interface (http://guides.rubyonrails.org/active_record_querying.html). Skim sections 8 to 11

5. Real Rails Guides Active Record Query Interface (http://guides.rubyonrails.org/active_record_querying.html). Read section 12 to see how Rails lets you play with joining tables together.

6. Real Rails Guides Active Record Query Interface (http://guides.rubyonrails.org/active_record_querying.html). Read section 16 for a quick look at the helpful find_or_create_by methods.

 If you want your application to run with any kind of efficiency at all, you should strive to reduce the number of queries that are run on your database as much as possible. That means figuring out ahead of time exactly what you’re looking for and then building the correct query to grab that thing one time onlIt’s okay to grab the SAME information multiple times. Rails caches the first result anyway so it doesn’t result in a performance hit. But there are situations where you force the ActiveRecord::Relation that is returned by a query to execute itself immediately and then you try to run queries on each member of the collection. That’s a whole lot of queries and can quickly slow your application down to a snail’s pace.

The N + 1 query problem is the classic case of this.  You grab all the records for your users (User.all) then loop through each user and call an association it has, like the city the user lives in (user.city). For this example we’re assuming an association exists between User and City, where User belongs_to a City. This might look like:

    User.all.each do |user|
      puts user.city
    end

This is going to result in one query to get all the users, then another query for each user to find its city through the association… so N additional queries, where N is the total number of users. Hence “N+1” problems. Note that it’s totally fine to just grab a regular attribute of User like user.name. It’s because you’re reaching through the association with City that we’ve got to run another full query.

If the best way to make an application run faster is to reduce database calls, we’ve just messed up badly by causing a potentially huge number of them.

Rails is well aware of your distress and has provided a simple solution — “eager loading”. When you first grab the list of all users, you can tell Rails to also grab the cities at the same time (with just one additional query) and store them in memory until you’d like to call upon them. Then user.city gets treated the same way as user.name. It doesn’t run another query. The trick is the #includes method.

#includes basically takes the name of one or more associations that you’d like to load at the same time as your original object and brings them into memory. You can chain it onto other methods like #where or #order clauses.

Note: One thing which can be a bit annoying from a development standpoint is that I haven’t found an easy way to “see” your eager-loaded fields by looking at the output from your Rails server. So don’t be alarmed if they don’t show up in the server output.

Almost as useful is the #pluck method, which is covered in the Rails Guide. #pluck lets you skip several steps in the process of pulling up a bunch of records, storing them in memory, then grabbing a specific column and placing it into an array. #pluck just gives you the resulting array right away:

    User.pluck(:name)
    # => ["Foo", "Bar", "Baz", "Jimmy-Bob"]

This is another way to help speed up your application if you’ve found pain points. Start by getting rid of N+1 queries, though.

Scopes are underappreciated and awesome and very simple. A scope is basically a custom chain of ActiveRecord methods that you can slap onto an existing Relation by calling its name like a normal method. It’s easiest to see in an example.

Let’s say you let your user choose to filter your blog posts only for those marked “important”:

    # app/models/post.rb
    ...
    scope :important, -> { where(:is_important => true) }
    ...

    # app/controllers/posts_controller.rb
    ...
    def index
      if params[:important] == true
        @posts = Post.important.all
      else
        @posts = Post.all
      end
    end

This is a pretty simple example. Instead of always having to rewrite that chain of ActiveRecord methods when you want them, you can create nicely named scopes to contain all the component logic. You reduce repetition and make your code more readable. The best part is that scopes return Relations… so you can chain as many of them as you want.

You might be thinking, Why use a scope when you can write a class method to do the same thing? You can, as long as your class method returns a Relation (which can take some additional thought for edge cases). In fact, using a class method is often best if your logic chains are quite complicated. The example above could be solved using the following class method as well:

    # app/models/post.rb
    ...
    def self.important
      self.where(:is_important => true)
    end
    ...

See the Additional Resources section for links to some posts that dig a bit deeper into the use cases for these two.

How much do you need to understand or care about scopes? In the early going, you probably won’t run into them or see why to use them. Keep them in the back of your mind for when you start working on some slightly more complicated projects that might need them.

Sometimes, you just can’t get ActiveRecord to do what you want it to. In that case, it gives you an interface to the bare metal SQL so you can just type in your query as desired. This should really be a last resort. It’s basically hard-coding your application code. Use the #find_by_sql method for this.

1. Read Rails Guides Active Record Query Interface Chapter 14  (http://guides.rubyonrails.org/active_record_querying.html) for a look at Scopes. Again, you don’t necessarily need to memorize all the details of scopes, but understand the concept and when it might be useful.

2. Read Rails Guides Active Record Query Interface Chapter 17  (http://guides.rubyonrails.org/active_record_querying.html)or a look at using SQL directly.

At the most basic level you can do pretty much anything you can in SQL by using Active Record query methods. You’ll get a chance to use some of these new found query methods in future projects and others will come up when you’re building things on your own.

Dive into some of the more interesting features of associations like special methods and polymorphism.

A brief look at the life-cycle of an Active Record object, from birth to destruction, and how you can hook into that for profit.

Active Record Callbacks

Introduction

Callbacks are a common way for you to execute code at specific times in the life cycle of an Active Record object, for instance just before it is created, after it is saved, or after it is destroyed. These can be very useful if you’ve got something to execute whenever an object hits one of those lifecycle points, like modifying the user’s email to be lowercase when creating her account. Callbacks are a way of saying something like “Hey Active Record, when you’ve finished creating a new User object, give me a call so I can run this method before anything else happens.”

This is a brief section on a useful topic. The Rails Guide reading provides good coverage of it, so my summary will be necessarily brief.

Points to Ponder

Look through these now and then use them to test yourself after doing the assignment

• What is a callback used for?
• What are the major lifecycle stages of an Active Record object?
• How do you build an “around” callback?
• How do you specify a particular action to run a callback for?

The Life Cycle of an Active Record Object

Callbacks provide hooks into specific points (either before, after, or sometimes “around”) in the life cycle of an object. Those life cycle moments are:

• Initialization — When the object is first built OR whenever it is reloaded from the database and into memory (so any time you find it in a query).
• Validation — whenever Rails checks if the object is valid. That could be when you’re trying to save it or if you’ve manually run the #valid? method.
• Saving — The actual act of saving an already-built object to the database. This is triggered any time the object is saved, not just the first time it is created.
• Creating — The creation and saving of a new object.
• Updating — The updating of an existing object.
• Finding — When you’ve searched for the object. Often gets triggered by Rails working with objects behind the scenes (e.g. when )

You often get three choices for callbacks. Not all object lifecycle steps support all callbacks, but the basic three are (using create as an example):

1. before_create — Runs the method before the stated action
2. after_create — Runs the method after the stated action
3. around_create — A bit trickier. In this one, you will write a method which actually yield‘s at some point to the original action. That way you can have code before it and after it and YOU decide at which point the original action gets done. Not entirely common.

Using Callbacks

To use a callback, you need to “register” it at the top of your Model by using the appropriate method (e.g. before_create). You pass that method either a symbol which corresponds to a method name or you could just write the callback as a block then and there. Rails will hang onto that method and call it at the appropriate time. For example:

    # app/models/user.rb
    class User < ActiveRecord::Base
      before_create do |user|
        puts "about to create #{user.name}"
      end
      after_create :just_created

      protected
      def just_created
        puts "just created a user"
      end
    end

Specifying Callback Characteristics

Callbacks give you several options for narrowing down or selecting specifically when you want them to run. If you only want to run a callback when a particular controller action calls it, use the :on option, which takes either a single symbol or a full array, e.g. before_create :run_code, :on => [:create, :update].

You can also use conditional logic options :if and :unless to try a method before running callbacks, for instance:

    ...
    before_create :run_code, :unless => :method_is_true

    protected
    def method_is_true
      true
    end
    ...

Transaction Callbacks

Sometimes your Rails app will need to interact with an external application (which is inherently imperfect) as a part of the save process. Other times your save will involve juggling several balls at once and, if one fails, they all need to be rolled back. Typically these cases will involve wrapping your database save operation in a “transaction”, which means that either all the steps work or they all fail and are rolled back.

The committing of a transaction and its potential rollback if it fails are both lifecycle events that you can latch onto with callbacks, e.g. after_commit and before_rollback. This is uncommon, so consider it another one of those “just remember that it’s an option” type things.

Your Assignment

1. Read through the Rails Guide on Callbacks
2. Read this post from Samuel Mullen on guidelines for using callbacks.

Conclusion

Callbacks are useful and many, like :after_create and :before_destroy are pretty common. There’s no rocket science here, just a helpful concept.

Additional Resources

This section contains helpful links to other content. It isn’t required, so consider it supplemental for if you need to dive deeper into something

• WikiBooks Reference on Callbacks

Take what you know about forms and put rocket boosters on it. Don’t be afraid to make a form for anything.

Advanced Forms

Introduction

You learned about the basics of building forms in HTML and Rails in previous lessons and you can do a whole lot with that knowledge. But there are also cases when crafting a good user experience demands building a form that handles multiple things (e.g. model objects) at once. Users only like clicking the submission button once so you’d better be able to give them the simple experience they demand.

In this section, we’ll take a look at some of the options you have to make a form handle multiple model objects at once. You’ll also learn how to prepopulate a dropdown menu with objects.

Points to Ponder

Look through these now and then use them to test yourself after doing the assignment

• How do you prepopulate a dropdown menu with data?
• What is the difference between the #select_tag helper and the #select helper?
• What format does the array you input to #options_for_select need to be in?
• Why would you need to use a nested form?
• What do you need to change in the model to allow nested forms to create new objects properly?
• How do you whitelist the nested parameters properly in your controller?
• Why can’t you just delete something by leaving a form field (e.g. a checkbox) blank (unchecked)?

Prepopulating select Tags with Collections

Rails provides you with a few handy ways of making dropdown menus which already contain data when the form is loaded (otherwise they’re not that useful).

Let’s say you want to build a New Post form for your blog but you want to be able to select who the author is from among your list of users. You will need to make a dropdown which submits the user’s ID as a part of your params hash. So you might populate @users in your posts controller:

    # app/controllers/posts_controller.rb
    ...
    def new
      @users = User.all
      @post = Post.new
    end
    ...

The bare HTML way is to build a bunch of <option> tags (inside your <select> tag). You could easily create these in your ERB code by just iterating over some collection, for instance if you’d like to select a post to view from a list of them.

    # app/views/posts/new.html.erb
    ...
    <select name="user_id">
      <%= @users.each do |user| %>
        <option value="<%= user.id %>"><%= user.name %></option>
      <% end %>
    </select>
    ...

This creates a dropdown list with each user’s name as an option. Your #create action will receive an attribute called user_id and you can use it to match an author to that post.

But Rails provides some less verbose ways of doing the same thing, namely using the #select_tag helper in conjunction with the #options_for_select helper. The #select_tag will create the surrounding tag while the #options_for_select gives #select_tag the array of options it needs.

#options_for_select expects a very specific input — an array of arrays which provide the text for the dropdown option and the value it represents. So options_for_select([["choice1",1],["choice2",2]]) creates a couple of option tags, one for each choice. This is great, because that’s exactly what #select_tag expects for its second argument. The only wrinkle here is that you need to convert your @users collection, which has full User objects, into a simple array with just name and value. That’s easy using #map:

    # app/controllers/posts_controller.rb
    ...
    def new
      @user_options = User.all.map{|u| [ u.name, u.id ] }
      @post = Post.new
    end
    ...

    # app/views/posts/new.html.erb
    ...
    <%= select_tag(:author_id, options_for_select(@user_options)) %>
    ...

So just pass #select_tag the name it should use for your chosen value and the collection and it will output the exact same thing!

If you want to avoid the whole options_for_select thing altogether and your form is designed to build a model instance (e.g. a Post object), just use the more generic #select helper in your view:

    # app/views/posts/new.html.erb
    ...
    <%= select(:post, :author_id, @user_options) %>
    ...

You still need to pass it the :post parameter (which indicates that your form is building a Post object) so the select tag can get the name right… in this case, it will name the tag <select name="post[author_id]" id="post_author_id">. That means (remember!) that the author_id attribute will show up in your params nested under the post hash.

The :author_id input to the #select helper above represents not just what the chosen value should be called (as in the #select_tag) but also which column name it represents in your original (in this case Post) model. This may be a bit annoying at first since you can’t just name your choice whatever you want.

If you have a #form_for form scoped under the f variable, you don’t need to pass the :post symbol above (it gets it from f), so could instead use:

    # app/views/posts/new.html.erb
    ...
      <%= f.select(:author_id, @user_options) %>
    ...

It took a bit of time for us to get here, but hopefully you can now see how straightforward this method is for generating a potentially large dropdown.

You’ll use dropdowns a lot to populate the association of a model, e.g. the author of a Post. In the next section, we’ll talk about how to actually create both model objects from within a single form.

Note: If you’ve used the simple_form gem, it has its own way of handling collections of objects which is a bit different (supposedly simpler) than this.

Nested Forms

You’ve got a form for creating one of your User objects (say for your Amazon.com clone application) but you also want to make that form create one or more ShippingAddress objects (which a User can have many of). How do you get that one form to create both so your user doesn’t get stuck clicking a bunch of form submits?

This is a multi-part process. It involves your controller, view, models and routes… the whole MVC team! The gist of it is that your form will submit the main object (e.g. the User) as normal but it will sneak in a bunch of attributes for the other object(s) you want to create (e.g. ShippingAddress object(s)). Your model will have to be ready for this. It will create not just the original User object but also the nested objects at the same time.

As you can imagine, it’s important to get the names and parameters properly listed so all this magic can happen behind the scenes.

We’ll do a broad overview of the process here:

1. You will need to prepare the User model so that it knows to create one or more ShippingAddress objects if it receives their attributes when creating a normal User. This is done by adding a method to your User model called #accepts_nested_attributes_for which accepts the name of an association, e.g:

       # app/models/user.rb
       class User < ActiveRecord::Base
         has_many :shipping_addresses
         accepts_nested_attributes_for :shipping_addresses
       end
   

2. Make sure you’ve allowed your params to include the nested attributes by appropriately including them in your Strong Parameters controller method. See the reading for examples of how to do this.
3. Build the form in the view. Use the #fields_for method to effectively create a #form_for inside your existing #form_for form.

There are a couple new aspects to this process. You saw #fields_for in the Basic Forms lesson but it probably has new meaning to you now. It’s basically how you create a form within a form (which should make sense since it’s actually used behind the scenes by #form_for). In this example, we might create three “sub-forms” for ShippingAddress objects by using our association, e.g.

    <%= form_for @user do |f| %>
      ...
      <% 3.times do %>
        <%= f.fields_for @user.shipping_address.build do |addy_form| %>
          ...
          <%= addy_form.text_field :zip_code %>
          ...
        <% end %>
      <% end %>
      <%= f.submit %>
    <% end %>

Note that we could (and should) also have built the new shipping_address objects in the controller instead of the view; it’s just for demonstration purposes here.

The #accepts_nested_attributes_for method is fairly straightforward and the docs should be helpful.

The reading will cover more about whitelisting the nested parameters.

Deleting Nested Form Objects

You can also have your form destroy nested forms by first setting the :allow_destroy option to true for the #accepts_nested_attributes_for method, e.g. accepts_nested_attributes_for :shipping_addresses, :allow_destroy => true. Now, any time you want to destroy a ShippingAddress object from a User’s form, just include the key _destroy => 1 in the submitted parameters for that ShippingAddress.

Many-to-Many Relationships

If you’ve got a has_many :through relationship, you’ll likely need to go one additional step further by specifying that each side of your relationship is the inverse of the other. It’s detailed in this blog post from ThoughtBot.

Designing Your Own Forms

Sometimes, despite all the nice helpers Rails gives you, you just want to do something that’s not standard. You should first wonder whether this is the easiest and most straightforward way to do things. If it passes the smell test, then go ahead and build your form.

It’s often easiest (and good practice while you’re learning) to start with the most basic of HTML forms. If you don’t understand what’s going on in the basic HTML (and remember to include your CSRF token), then you’ll be hopeless trying to use helpers. Once you’ve got a good handle on things, gradually bring in the Rails helpers like #form_tag and #form_for.

Don’t get discouraged if you get some real head-scratcher moments when building nonstandard forms. It just takes some experience to feel comfortable. And if things are too out of hand, you may need to re-evaluate your approach (what exactly are you hoping to accomplish with your complex form?) and start again.

Simple Form

simple_form is a gem by Platformatec which can really make your life easier (if you aren’t doing anything too crazy). It provides lots of user-friendly features for building forms and is in wide use today. We won’t cover it explicitly here (though it’s used in the tutorial we’re following).

It’s up to you to check out the documentation and start using it in your own applications as desired.

Miscellania: Blank Submissions That Mean Delete

Sometimes, for a record that already exists, you want to either deselect a dropdown or check none of your checkboxes but you want this to indicate that the associated fields should actually be set to nil. Usually, though, if you submit the form it will include none of the fields and your back end won’t know that you actually wanted to remove those fields so nothing will happen. How do you get around it?

Try making a hidden field in your form (or nested form) that has the same name as your checkboxes or dropdown but only contains the value "". Now you’ll get that attribute to show up in your params hash no matter what and you can handle deleting the records however you’d like appropriate.

Sometimes Rails helper methods will do it for you, but make sure you know what your form is actually submitting (if anything) if you deselect all options!

Your Assignment

1. Read the Rails Guide on Forms sections 3.3, which covers populating a form with a collection of objects.
2. Read the Same Rails Guide on Forms section 9, which covers accepting nested form data.
3. Read the Same Rails Guide on Forms section 7, which covers the parameter conventions for nested forms.
4. Read this blog post from Peter Rhoades on working with nested forms. The example covers a lot of the things we’ve gone over so far, so follow along. Also note how he does the whitelisting of nested attributes in Rails 4.

Conclusion

We’ve covered two of the more common use cases for complex forms — pre-populating a form with objects and creating multiple objects with a single form. At this point, even if you’re uncomfortable, you should have all the tools you need to work through creating a form. We’ll get your hands dirty in the project, have no fear.

The best part? This is more or less the most complicated conceptual stuff with learning Rails. Actually, it’s not even really Rails-specific… once you’re comfortable with the HTML that forms require and how the parameters get submitted to your controller, mapping that to the correct Rails conventions or helpers is the easy part. So everything you’ve learned may just be transferrable to every form you’ll ever make.

Additional Resources

This section contains helpful links to other content. It isn’t required, so consider it supplemental for if you need to dive deeper into something

• Simple Form Documentation on Github
• acceptsnestedattributes_for documentation
• Another example of a nested form on SO
• Using inverseof to make acceptsnestedattributesfor work for has_many :through relationships
• Understanding Rails’ form authenticity tokens
• Why not to hardcode your application’s secret token in production