rails magic : form_for

When refactoring forms, I often find that I have eschewed rails magic in favor of needlessly verbose statements. In this post, I will closely examine the form_for helper in order to determine exactly what shortcuts it offers.

form_for ‘binds’ a form to a model object that you declare.

<%= form_for @cheese %>

In this case we have binded our form to our Cheese model. To create a new instance of Cheese , we have a method in our controller that probably looks something like this.

class CheeseController < ApplicationController
    def new
      @cheese = Cheese.new
    end
    def create
      @bowl = Bowl.create(bowl_params)
      @bowl.save
      Player.add_new_bowl
      redirect_to bowls_path
    end
 end

The form_for method creates a form builder object that is expressed with the f variable. You can call a myriad number of methods on f to generate your HTML form.

<%= form_for @cheese do |f| %>
  <%= f.label_tag :stinkiness, "Stinkiness" %>
  <%= f.text_field :stinkiness %>
  <%= f.submit "Create" %>
<% end %>

The above ERB will generate the below HTML.

<form accept-charset="UTF-8" action="/cheeses" class="cheese"   id="new_cheese" method="post">
  <label for="stinkiness">Stinkiness</label>
  <input id="cheese_stinkiness" name="cheese[stinkiness]" type="text" /><br>
</form>

So what did we get from our form_for?

Well, we never specified whether we wanted to create a new instance of cheese, or update an old one. Because of form_for, Rails knew to call record.new_record?, and determined that the method called should be ‘create’, and not ‘patch’. We saved ourselves the trouble of writing the following line of code.

form_for(@cheese, url: {action: "create"})

Had our record already existed and our goal was to update, we would have saved writing the following line of code.

form_for(@cheese, url: cheese_path(@cheese), html: {method: "patch"})

Also, form_for created a new key in the params hash called params[:cheese], that has all the input fields as key-value pairs. This is particularly useful when editing multiple objects in the same form with the fields_for tag.

The last benefit of form_for is in the realm of routing namespaces. If in our routes we had code like this:

namespace :charcuterie do
  resources :cheeses
end

We could specify to our form the correct path and action with form_for simply by using the below code.

form_for [:charcuterie, @cheese]

This has been a brief summary of the magic of form_for. Stay tuned for future snippets on choice bits of rails magic.

Who Makes a Better Coder?

the rigid taskmaster, or the free-floating esoteric…

The idea that struck me most about Sarah Pei’s presentation was that to create, successful one must fully embrace the dynamism of their own personality. To explain, Sarah invokes the famous Walt Whitman quote from Leaves of Grass:

It turns out that creative people are not defined by their age, race, gender, or even intelligence. What creative people share are successful habits. What most of their habits have in common is some element of context change.

You must base yourself in what you do know, before leaping into the unknown. Sarah calls the example of Twyla Tharp – one of the most successful choreographers in American dance. Thyla is 72 years old, and for the last 40 years she has repeated the same process of organized context change. In the mornings, she practices moves she has repeated thousands of times. It is a rote, comfortable exercise. Every afternoon she experiments, drawing on the core elements she reinforced that morning, to let chaos reign, and gives herself permission to try new movements. She executes, and she then creates.

So how does this translate to coding?

Coding is a creative process, as well as an intensely directed one. To succeed at any scale, one must occupy both provinces. We need context change to reach our apex productivity, but what exactly is context change in the context of coding?

Simply put, it’s chopping things up. It’s learning to tie knots in the middle of the day. It’s changing from the couch to the orange springy stool. It’s pair programming.

Perhaps most fundamentally, it’s our FS class composition. Sarah’s presentation cites research that shows teams comprised of VISIBLY DISSIMILIAR individuals perform better than homogenous peer teams.

On a more structured level, it looks like this:

So, the next time my tests aren’t passing for the 80th consecutive time, and I’m throwing up hail mary methods, convinced that Ruby is broken, I’m going for a walk. And it’s going to be the most productive thing in the world, because we need both contexts to perform optimally.

To think of it in terms of coffee- I often wake up in the morning with a few weird ideas bumping around in my cerebral stew… fresh ideas that originated in the context of sleep, in the whitespace afforded by dreams. That’s a powerfully creative state of mind that I crave, but if I didn’t get up and have my coffee, I’d lay in bed all day dreaming.