I love me some nested attributes in Rails, but I’ve run into some gotchas in the past few days on 2.3.4 that I’m documenting here in hopes of saving time for some wayward programmer.
Ground rules: it’s common to pre-build associated objects in the controller in order to pass a model to the form helper, like so:
# In the controller
def new
@child = Child.new
@child.build_widget
end
AR#becomes is helpful when building forms for STI models, since it casts your child object as the parent class, thereby generating a route that points to the parent controller. In the common case where you have a form with a drop-down that lets you select the child class, this is the route you want:
# In the view
- form_for @child.becomes(Parent) do |form| # Posts to parents_path
- form.fields_for :widget do |widget_form|
But behold, in this case, the built Widget object will not be available to the form helper in the fields_for call. Instead, nil is passed and you’re certain to witness a NoMethodError. What happened?
It turns out that AR#becomes creates a new object of the specified class and clones three ivars to maintain state – @attributes, @attributes_cache, and @new_record. When you call #build_widget on the child object, however, it creates a new ivar, @widget, to hold the new record. Since this doesn’t get copied over, our associated Widget never makes it to the form helper and kablooey.
The workaround? Coerce the correct route another way:
- form_for :parent, @child do |form| # Also posts to parents_path
Not as expressive, but it gets the job done. Finally, I’m not positively sure that this is a bug in Rails. That is, it may be too dangerous to copy over every ivar to the new object, and it may be too cumbersome to try and detect the safe ones.
Say you have the following:
class Book < ActiveRecord::Base
belongs_to :person
accepts_nested_attributes_for :person, :allow_destroy => true
When you delete the nested object:
book.person_attributes = {:id => book.person_id, :_delete => true}
book.save
The person will be deleted, but the person_id on the book will retain the now-invalid id. This is especially problematic if foreign key constraints are involved and the database will certainly yell at you for breaking integrity.
The solution is creating the mirrored association and specifying that the foreign key should be nullified:
class Person < ActiveRecord::Base
has_many :books, :dependent => :nullify
Now, book.save updates the Book first, setting person_id to nil, before it destroys the Person. Again, this doesn’t seem like a bug, since the mirrored association appears to be the Right Thing To Do anyway. Then again, maybe I’ll change my mind and fire off a couple of Lighthouse tickets.
I have high hopes for Yehuda’s bundler – config.gems has always been troublesome and I like the merb approach of simply creating a local gem repo just for your app. With that, a few observations after diving in…
It doesn’t like source "http://gems.github.com" for now. There’s an open issue for it.
Dropping the suggested require at the top of boot.rb does the trick for Rails, but it doesn’t make use of other environments, if you have them defined (that’s the :only => [:test, :cucumber] bit).
A quick fix at the top of Rakefile:
ENV['BUNDLER_ENVIRONMENT'] =
case ARGV[0]
when /^features/ then "cucumber"
when /^(spec|test)/ then "test"
else "default"
end
require(File.join(File.dirname(__FILE__), 'config', 'boot'))
Then in boot.rb, subsititute the initial require with:
require File.expand_path(
File.join(
File.dirname(__FILE__),
'..', 'vendor', 'gems', 'environments',
ENV[ BUNDLER_ENVIRONMENT'] || "default"
)
)
At the very least, this loads the test and cucumber environments when running rake spec and rake features respectively.
Finally, if you see these:
config.gem: Unpacked gem cache in vendor/gems has no specification \
file. Run 'rake gems:refresh_specs' to fix this.
config.gem: Unpacked gem cache in vendor/gems not in a versioned \
directory. Giving up.
You can add the following line to config/environment.rb to suppress these warnings:
Rails::VendorGemSourceIndex.silence_spec_warnings = true
Update on August 25: looks like everything I’ve mentioned above has been resolved as of the 0.5.0.pre release. Awesome. I wonder if this is being folded into Rails 3?
Google Voice is here. When it comes time to pick your Google number, they provide a search tool that scopes by area or ZIP code as well as strings of letters and numbers. I quickly tried my name, to no avail, and then began searching for that elusive ten-character phrase.
To that end, here’s a quick script that will let you input T9 numbers and spit out matching words. Give it something like:
$ ruby t9.rb 347 10
And it’ll spit out words that begin with the T9 numbers “347”, up to ten characters in length. Good luck.
My iPhone is not a toy. I’ve tried conveying as much to my toddler, but she still pines after it and has managed to grab it on a few occasions. Thankfully, she doesn’t fly off in a tear, but rather, plops rights down, fully absorbed.
It’s fun to watch her with the phone – tapping around, pressing the buttons, calling people – and now, she really seems to get the interface. She scrolls lists, browses photos, and taps buttons expecting results. Any doubts I have about the interface are vanquished by watching her use the phone. It just comes to her so naturally.
Of course, now she touches other displays and gets frustrated by the lack of interaction. Maybe soon all screens will be touchscreens, but engineers and interface designers better hurry up, lest they fail to meet the expectations of a different generation.
There’s nothing like late night improvements to your editor. Tonight’s finds:
And for those so interested, my .emacs file can be found on github.