#form helpers

One of the more frustrating experiences I've had as a beginning rails developer is figuring out the form helper. When I first encountered it, I immediately wondered what the point of it was. Why do I need this, my html forms work perfectly fine? I think the reason I clung to my html forms was because it was one of the few things I was familiar with, and with all the new stuff I was learning, I held tight the few familiar things I had to work with. Now that I understand what's going on in Rails a little better, I'm prepared to admit that form helpers are indeed extremely useful.

form method="post" action="/hats" input type="hidden" value= %= session[:_csrf_token] % name="authenticity_token" input type="submit" value="Generate Match List" /form

That little piece of beauty was my come to Jesus moment. For this button I passed in a Ruby CSRF token as a value, which was a good catch on my part as it ensured the button was protected from cross site request forgery. But the way I did it is pretty silly if you know that with a simple form helper, the CSRF token is passed in automatically (as long as the default security feature is enabled). Here is a basic form_tag, followed by the html it automatically generates:

%= form_tag do % Form stuff % end % form accept-charset="UTF-8" action="/home/index" method="post" div input name="utf8" type="hidden" value="✓" input name="authenticity_token" type="hidden" value="f755bb0ed134b76c432144748a6d4b7a7ddf2b71" Form stuff /div /form

Why it has to put those div tags in there I'm not sure, but according to the Rails Guides they are necessary to send the data. Another one of my forms contained radio buttons and a text field:

%= radio_button_tag(:participating-yes) % %= label_tag(:yes, "Yes") % %= radio_button_tag(:participating-no) % %= label_tag(:no, "No") % %= text_field_tag(:interests) %

These helpers generate the necessary html input attributes to pass form data as a ruby object directly to it's route.

input id="participating-yes" name="age" type="radio" value="true" label for="yes" Yes /label input id="participating-no" name="age" type="radio" value="adult" label for="no" Yes /label input id="interests" name="interests" type="text"

So again today we worked solo, and again we worked on nested user input forms (i.e. a form within a form within a form... ad nauseum).

Seeing that the assignment was strangely short and simple, and that I had freedom to choose my own approach (no pair to worry about), I decided that I would take the opportunity to ditch direct HTML and acquaint myself with Rails' form helpers.

It really is a lot cleaner to use these, though they're also more complicated, so it took me a while to get it working. Some people had finished the project by lunch, whereas I took until 3:45. The problem I got stuck on for the longest time had to do with the fields_for method.

cat .non-rubyists-ignore

Let's take a look at my code:

<%= form_for(@newspaper) do |f| %> ... <h2>Subscriptions:</h2> <%= f.fields_for "subscriptions_attributes" do |subs_fields| %> <% @newspaper.subscriptions.each do |sub| %> <%= f.fields_for sub do |sub_fields| %> <%= sub_fields.text_field :price %> ... <% end %> <% end %> <% end %> <%= f.submit %> <% end %>

My intention was to mass-assign Subscription objects, which were in a different table than the Newspaper object which was being processed in the form. To do this, I needed an association between the tables, an accepts_nested_attributes_for :subscriptions set up in my Newspaper model, along with subscriptions_attributes added to attr_accessible.

All of this I had done, so in form above, I was trying to get a nested parameters hash for price that looked like this:

newspaper[subscriptions_attributes][X][price]

where X was a set of unique dummy keys. But I wasn't getting unique keys, I was getting this:

newspaper[subscriptions_attributes][subscription][price]

I tried adding an index, but that gave me too many keys:

newspaper[subscriptions_attributes][subscription][X][price]

As it turns out, Rails documentation is pretty sparse out here on the margins. It took me a fair amount of trial, error, and internet trawling before I finally found my answer here. As it turns out, I only needed one loop for the three I had tried.

<%= f.fields_for "subscriptions_attributes" do |subs_fields| %> <% @newspaper.subscriptions.each do |sub| %> <%= f.fields_for sub do |sub_fields| %>

became simply:

<%= f.fields_for :subscriptions do |sub_fields| %>

And thus, we see Rails magic at work yet again. Passing a symbol in to fields_for automatically associates that part of the form with the corresponding method on the form_for object, and Rails will find the appropriate keys to make that assignment work.

So in this case, the symbol :subscriptions will be used to call @newspaper.subscriptions and pre-populate the form with any relevant data, and because it's a collection, Rails knows to iterate through it and add unique dummy keys. Then Rails will assign the appropriate input names (since we'll be assigning subscriptions, the names will have to include subscriptions_attributes plus a dummy key).

Solo day today. I made an app that allows teams of users to allocate projects and mark down completed items. It's fancier than my last couple of Rails apps. I've been incorporating all sorts of recently learned things like nested routes, local variables passed in partials, dynamically generated tab titles, styling with Bootstrap, flash notices on validation errors and successful transactions, and, my favorite, metaprogramming.

So here's the thing, Rails form helpers are great-- but they fail woefully when it comes to check boxes. In some cases a single check box suffices, and Rails has accounted for those cases (albeit in a clunky fashion). Many times, though, you'll want a whole bunch of check boxes all relating to a single entity, say friends to add to a group message. Rails forces you into a lot of legwork to implement this.

What I was looking for was a check box field. Since Rails didn't have a form helper for that I created my own. But first, let's look at what Rails would have made me do without my helper.

First you have to wrap the check box tag in an iterative loop to get at the object you'll be using to make it. You have to manually pass the check box name, infer the check box value from the object's id, do an expression to set default checked status, and build up an id for the checkbox. Then you lop on a label to match to each check box, and once you're out of the loop, add in a hidden sentinel field to ensure that the values are updated

Assume that we're in the users/edit view with @user object passed as a variable from the UsersController. The name of the model is User.

<% User.friends.all do |friend| %>   <%= check_box_tag (     "user[friend_ids][ ]",     friend.id,     @user.friend_ids.include?(friend.id),     id: "user_friend_id_#{friend_id}"   ) %>   <%= label_tag "user_friend_id_#{friend_id}", "friend.name %> <% end %> <%= hidden_field_tag 

Yowch. That's some tedious code. With my helper it condenses down to:

<%= check_box_field :user, Friend, :name %>