Ryan's Scraps

If any of you Rubyists are going to be attending the FutureRuby in Toronto this July and have an interest in learning how to work some magic on the iPhone, I encourage you to check out Mobile Orchard’s Dan Grigsby and his Beginning iPhone Programming For Rubyists course taking place before FutureRuby. In addition to the iPhone basics, he’ll be covering our ObjectiveResource framework.

You can get a discount on the course if you register before June 9th so head on over and give it a peek.

I’m not sure if this was ever stated explicitly has a preferred practice or not, but for the longest time many of us have recognized that using migrations as a way to populate the database with a base configuration dataset is wrong. Migrations are for manipulating the structure of your database, not for the data within it and certainly not for simple population tasks.

Well, this practice now has a formal support in Rails with the addition of the database seeding feature. Quite simply this is a rake task that sucks in the data specified in a db/seeds.rb. Here are the details:

Specify Seed Data

Add or open the db/seeds.rb file and put in model creation statements (or any ruby code) for the data you need to be present in order for your application to run. I.e. configuration and default data (and nothing more):

1
2

[:admin, :user].each { |r| Role.create(:name => r) }
User.create(:login => 'admin', :role => Role.find_by_name('admin'))

Load the Data

Once that is in place you can run one of two rake tasks that will populate the database with this data: rake db:seed which will only populate the db with this data and rake db:setup which will create the db, load the schema and then load the seed data. This is the task you’ll want to use if you’re starting in a fresh environment.

So, quit overloading your migrations with seed data and use this new facility. But, don’t go overboard and use seeds.rb for test or staging datasets – it should only be used for the base data that is necessary for your app to run.

tags: ruby, rubyonrails

There are often times when you want an update made to one object to be reflected up the object graph as an update of an associated parent object. For instance, if a new comment is created on an article, you may very well want to mark the article as being updated. With the new touch feature of ActiveRecord, this is a whole lot easier. Using our previous example, here’s is how it works:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class Article < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base

  # Make create/update/deletes of a comment mark its
  # parent article as updated
  belongs_to :article, :touch => true
end

# Adding a new comment marks the article as being updated
article.updated_at #=> "Mon Apr 20 07:42:53 -0400 2009"
article.comments.create(:body => "New comment")
article.updated_at #=> "Mon Apr 20 07:43:27 -0400 2009"

# Same for updates/deletes
article.comments.first.destroy
article.updated_at #=> "Mon Apr 20 07:45:23 -0400 2009"

This is a great way to keep tightly coupled domain models in-sync without resorting to a potential maze of callback logic.

Also, if you have a timestamp field named something other than the standard updated_at or updated_on you can explicitly specify that field as the value to the :touch option and it will get marked instead:

1
2
3
4
5
6
7
8
9
10
11
12
13

class Article < ActiveRecord::Base
  has_many :comments
  validates_presence_of :last_updated_at  # non-standard
end

class Comment < ActiveRecord::Base
  belongs_to :article, :touch => :last_updated_at
end

# Adding a new comment marks the article as being updated
article.last_updated_at #=> "Mon Apr 20 07:42:53 -0400 2009"
article.comments.create(:body => "New comment")
article.last_updated_at #=> "Mon Apr 20 07:43:27 -0400 2009"

Also, somewhat conveniently, you can invoke touch directly on a model to update its timestamp outside any association callbacks:

1
2
3

article.updated_at #=> "Mon Apr 20 07:42:53 -0400 2009"
article.touch
article.updated_at #=> "Mon Apr 20 07:43:27 -0400 2009"

So, touch away (in a non-creepy kind of way)!

tags: ruby, rubyonrails

ActiveRecord got a little batch-help today with the addition of ActiveRecord::Base#find_each and ActiveRecord::Base#find_in_batches. The former lets you iterate over all the records in cursor-like fashion (only retrieving a set number of records at a time to avoid cramming too much into memory):

1
2
3

Article.find_each { |a| ... } # => iterate over all articles, in chunks of 1000 (the default)
Article.find_each(:conditions => { :published => true }, :batch_size => 100 ) { |a| ... }
  # iterate over published articles in chunks of 100

You’re not exposed to any of the chunking logic – all you need to do is iterate over each record and just trust that they’re only being retrieved in manageable groups.

find_in_batches performs a similar function, except that it hands back each chunk array directly instead of just a stream of individual records:

1
2
3
4

Article.find_in_batches { |articles| articles.each { |a| ... } }
  # => articles is array of size 1000
Article.find_in_batches(batch_size => 100 ) { |articles| articles.each { |a| ... } }
  # iterate over all articles in chunks of 100

find_in_batches is also kind enough to observe good scoping practices:

1
2
3
4
5
6

class Article < ActiveRecord::Base
  named_scope :published, :conditions => { :published => true }
end

Article.published.find_in_batches(:batch_size => 100 ) { |articles| ... }
  # iterate over published articles in chunks of 100

One quick caveat exists: you can’t specify :order or :limit in the options to find_each or find_in_batches as those values are used in the internal looping logic.

Batched finds are best used when you have a potentially large dataset and need to iterate through all rows. If done using a normal find the full result-set will be loaded into memory and could cause problems. With batched finds you can be sure that only 1000 * (each result-object size) will be loaded into memory.

tags: ruby, rubyonrails

The iPhone is cool and sexy. Rails is cool and sexy. Shouldn’t they be a little more compatible?

We think so and have released the first version of ObjectiveResource, our port of Rails’ ActiveResource to Objective-C for the iPhone. We’ve used it extensively on some of our iphone projects and have gotten a good response from others that have stumbled upon it.

Basically, it provides an easy way to consume and integrate with Rails’ standard XML and JSON RESTful web-services (just as ActiveResource does for Ruby).

iPhoneOnRails.com is where we’re going to keep the development progress and planning for the framework as well as the various resources we’ve established for those that have questions and concerns. So have a look, play with the source yourself, join the mailing list and keep track at the iPhoneOnRails blog.

And let us know if you’re using ObjectiveResource and want to be featured on the site, or have a quote about using the framework you want us to put up.

Here’s a list of the major new features in Rails v2.3 (most recent first):

Rails 2.3 Features

• Batched find
• Nested Model Mass Assignment
• HTTP Digest Authentication
• Dynamic Scopes
• Application Generators
• Rails Metal
• No More Formatted Routes
• Object.try
• Simplified render
• application.rb Becomes application_controller.rb
• Default Scoping

The next scheduled release appears to be the 3.0 release, the merger of Rails and Merb. The core team has alluded to at least a preview release to be ready by RailsConf 2009. Seems a bit aggressive for all the internal tinkering in store, but stay here for for the latest.

You should also check out the Rails 2.3 release notes for the ‘official’ rundown of new features for 2.3.

tags: ruby, rubyonrails

We were all teased a few months ago about the possibility of finally solving the nested model/complex forms problem in Rails, but were then cruelly notified that it wasn’t quite ready for prime time. But our day has come – the most requested feature for Rails 2.3, the ability to handle multiple models in a single form, is here.

This API update was added after the original commit. I’ve updated the examples here to account for this.

This feature has already been written about on the Rails Blog quite well by Eloy Duran, the committer of this fine feature, so I’ll try not to replicate what’s already out there. However, here’s a basic rundown of what you need to do to get your models nested-form capable.

Step 1: Notify Your Model of Nest-able Associations

The first step is to tell your models which of their associations will be able to receive nested attributes. For all associations you want exposed in nested forms you’ll need to use accepts_nested_attributes_for:

1
2
3
4
5
6
7
8
9

class Person < ActiveRecord::Base

  validates_presence_of :name

  has_many :children, :class_name => 'Person'
  accepts_nested_attributes_for :children, :allow_destroy => true
    # can also be used on has_one etc.. associations

end

With this bit in place, you can now directly create, edit and delete children from a person:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# Add a new child to this person
@person.children_attributes = [ { :name => 'Son' } ]
@person.children #=> [ <#Person: name: 'Son'> ]
@person.children.clear

# Add two new children to this person
@person.children_attributes =
  [ { :name => 'Son' }, { :name => 'Daughter' } ]
@person.save
@person.children #=> [ <#Person: name: 'Son'>, <#Person: name: 'Daughter'> ]

# Edit the son (assuming id == 1)
@person.children_attributes = [ { :id => 1, :name => 'Lad' } ]
@person.save
  #=> the son's name is now 'Lad'

# Edit the daughter (id == 2) and add a new offspring
@person.children_attributes =
  [ { :id => 2, :name => 'Lassie' }, { :name => 'Pat' } ]
@person.save
  #=> the daughter's name is now 'Lassie' and there's a new offspring called 'Pat'

# Remove Pat (id = 3), we don't like him/her
@person.children_attributes = [ :id => 3, '_delete' => '1' } ]
@person.save
  #=> Pat is now deleted

• To support both the creation of new objects and the editing of existing ones we have to use an array of hashes for one-to-many associations or a single hash for one-to-one associations. If no :id property exists then it is assumed to represent a nested model to create.
• To delete an existing nested model, use this format: [ :id => pk, '_delete' => '1' } ] where the value of _delete evaluates to anything true. You must also set the accepts_nested_attributes_for option :allow_destroy to true as that capability is turned off by default.

While this may appear a bit hackish when you’re used to dealing with the pleasantries of a rich object model and with ActiveRecord’s associations, this provides the foundation for a seamless transition to the view where you need to create your nested model forms…

Step 2: Create a Nested Model Form

In the view, simply use fields_for on these nested models to expose the fields for each such model:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<% form_for @person do |person_form| %>

  <%= person_form.label :name %>
  <%= person_form.text_field :name %>

  <% person_form.fields_for :children do |child_form| %>

    <%= child_form.label :name %>
    <%= child_form.text_field :name %>

    <% unless child_form.object.new_record? %>
      <%= child_form.check_box '_delete' %>
      <%= child_form.label '_delete', 'Remove' %>
    <% end %>

  <% end %>

  <%= submit_tag %>
<% end %>

This will create a form with all the form fields necessary for submitting to a RESTful controller, transparently pushing your children_attributes onto the person.

If there are any validation errors on a child, they will be added to person.errors, and nothing will save if any of the children fail (i.e. fully transactional).

• Using fields_for on a has_many association automatically executes once for each nested model present, so think of yourself as being inside a loop when building your child_form
• If you ever need to change behavior based on the nested model currently in scope, it can be accessed via child_form.object. In this example we use child_form.object.new_record? to determine whether or not to display the delete checkbox (as that only makes sense on an existing record).

Step 3: In Your Controllers … Do Nothing

The third step should be the easiest, because we’re all dealing with purely RESTful controllers, right? The beauty of this solution is that it takes your controllers out of the mix and makes standard for submissions work perfectly with no interference at the controller level. Just so there’s no confusion, here’s how your create and update actions will look:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class PersonController < ApplicationController

  def create
    @person = Person.new(params[:person])
    @person.save ? redirect_to(person_path(@person)) : render(:action => :new)
  end

  def update
    @person = Person.find(params[:id])
    @person.update_attributes(params[:person]) ?
      redirect_to(person_path(@person)) : render(:action => :edit)
  end

end

Not a peep of those pesky nested models – with the rich support for nested objects at the model layer, it just works!

Extras

As with most powerful features, there are few little tweaks you may find yourself needing.

Default Create Form Fields

Often times you’ll want to have the form displayed with empty fields for easily creating a new nested model. For example, when a user goes to create a new person I want there to be fields for creating a new child already displayed.

Since the person object is brand new they have an empty children collection and no child_form fields will be displayed. There are two ways to get around this:

You can build a new nested object on the controller side (i.e. in the new action):

1
2
3
4
5

  def new
    @person = Person.new
    @person.children.build
    # ...
  end

which will cause there to be empty child_form fields displayed as desired. Or you can do it on the view side with a view helper:

1
2
3
4
5
6
7

module ApplicationHelper
  def setup_person(person)
    returning(person) do |p|
      p.children.build if p.children.empty?
    end
  end
end

Which can then be used within form_for to setup the person to the correct form state:

1
2
3

<% form_for setup_person(@person) do |person_form| %>
  <!-- ... -->
<% end %>

I prefer this view-helper approach as it really is a view concern (whether or not to display the form fields to create a new nested object by default).

Specify When Nested Models get Built

If you do have empty nested model form fields displayed by default, you’ll run into the issue where the user submits the form with no values filled in and you have to decide if you want to treat that as somebody trying to create a new nested item with no values, or if that means that no new nested item was submitted. Quite often you just want to ignore the submissions with no nested field values filled out.

Although I would have expected this to be default behavior, you need to manually specify that submissions with empty nested values are ignored using the :reject_if option of accepts_nested_attributes_for:

Note: You now have the option to use :all_blank to ignore the item if all properties are blank. See below for an updated example.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class Person < ActiveRecord::Base

  validates_presence_of :name

  has_many :children, :class_name => 'Person'

  # This will prevent children_attributes with all empty values to be ignored
  accepts_nested_attributes_for :children,
    :reject_if => proc { |attrs| attrs.all? { |k, v| v.blank? } }

  # This does the same thing using :all_blank
  accepts_nested_attributes_for :children, :reject_if => :all_blank

end

1
2
3

@person.children_attributes = [ { :name => '' } ]
@person.save
@person.children.count #=> 0

This is also useful if you have boolean values in your nested model fields (since, as a checkbox, ‘0’ will be submitted if there’s no value):

1
2
3
4
5
6
7
8
9
10
11
12

class Person < ActiveRecord::Base

  validates_presence_of :name, :bad

  has_many :children, :class_name => 'Person'

  # This will prevent empty checkboxes submitted for a child to be
  # construed as a submission
  accepts_nested_attributes_for :children,
    :reject_if => proc { |attrs| attrs['bad'] == '0' && attrs['name'].blank? }

end

1
2
3

@person.children_attributes = [ { :name => '', :bad => '0' } ]
@person.save
@person.children.count #=> 0

Dynamically Adding Nested Form Fields

If you want to allow the addition of a large number of nested models via your HTML forms, one option is to just have several empty nested forms displayed by default. This is a little unappealing, however. The far slicker option is to use javascript to dynamically display the new nested form on the user’s request.

Eloy has a great example application setup on GitHub outlining how this works, and I’ll let you take a peek over there to see how to wire up your dynamic nested form additions.

Eloy’s example app is also a great place to see how the whole thing works, end-to-end. By far the best resource out there.

Conclusion

So there it is, Rails’ most requested new feature in the flesh and blood. I’m not sure if my experiences are indicative of everybody else’s, but this is a godsend for me. Many thanks to all the folks involved with this functionality (if you don’t know who they are, check out the next section which links to a bunch of great resources). A really great effort by the community.

Resources

• Eloy Duran’s example nested model project
• The Lighthouse ticket for this feature with some good discussions
• The blog post on the official Rails blog
• The discussion of the various incarnations of this feature on the mailing list
• Ryan Bates’ Railscast on complex forms

tags: ruby, rubyonrails

Long ago, in your mother’s version of rails, we got a http basic authentication plugin. That functionality has since been rolled into Rails core, but it was always lacking HTTP digest authentication. Until this commit, that is.

For those that may now know the difference, basic authentication only base 64 encodes the authenticating username and password (making it easily decoded) whereas digest authentication sends an MD5 hash of your username and password. To simplify, digest is more secure than basic.

To request digest authentication in Rails, you’ll need to be able to retrieve the cleartext password for a given user (so the framework can hash and compare it using the nonce it created specifically for that request). This commit now allows you to also use a specific hashed format of the password. Here’s how this works if you have access to a cleartext password:

1
2
3
4
5
6
7
8
9
10
11
12
13

class ArticlesController < ApplicationController

  before_filter :digest_authenticate

  def digest_authenticate

    # Given this username, return the cleartext password (or nil if not found)
    authenticate_or_request_with_http_digest("Articles Administration") do |username|
      User.find_by_username(username).try(cleartext_password)
    end
  end

end

Most of us will want to do something with the result of the authentication and can do so with the boolean return value of authenticate_or_request_with_http_digest:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

class ArticlesController < ApplicationController

  before_filter :digest_authenticate

  def digest_authenticate

    success = authenticate_or_request_with_http_digest("Admin") do |username|
      (@user = User.find_by_username(username)).try(cleartext_password)
    end

    # If authentication succeeds, log the user in.  If not, kick back out a failure
    # message as the response body
    if success
      session[:user_id] = @user.id
    else
      request_http_digest_authentication("Admin", "Authentication failed")
    end
  end

end

If you don’t want to store clear text passwords you can return an MD5 hash from the authenticate_or_request_with_http_digest block as long as it’s in the format username:realm:password. You can get a password hash by using Digest::MD5::hexdigest.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class User < ActiveRecord::Base

  attr_accessor :password
  validates_presence_of :username, :crypted_password
  before_save :hash_password

  ...

  def hash_password
    if password_changed?
      self.crypted_password =
        Digest::MD5::hexdigest([username, "UserRealm", password].join(":"))
    end
  end
end

and then in your controller:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class ArticlesController < ApplicationController

  before_filter :digest_authenticate

  def digest_authenticate

    # Just return the crypted (hashed) version of the password if it's in the supported
    # format.  Note that the realm here "UserRealm" should match the middle
    # argument of your password hash
    success = authenticate_or_request_with_http_digest("UserRealm") do |username|
      (@user = User.find_by_username(username)).try(crypted_password)
    end

    ...
  end

end

So there you have it, digest authentication in edge Rails.

tags: ruby, rubyonrails

Nested Model support in Rails is currently scheduled for Rails 2.3. Yay!

The Rails team has recently organized its community around the Rails Activists group and provided several ways for you to speak your mind about the framework – and one of the best ways to impact the maturation of the framework is to vote for features you’d like to see in upcoming releases.

While I don’t usually like to use this site as a bully pulpit, I have to say that the one feature I’d love to see make it’s way into Rails is nested model mass assignment support. The team teased us with the foundation of an initial implementation but later yanked it since it didn’t quite cover all the cases.

I’ve setup a suggestion on uservoice for exactly this feature. If you’d like to see this support in Rails vote for it now! to be heard.

By the way, I totally acknowledge that I am being less than useful here only in complaining and not actually contributing. Guilty as charged – but to be honest, it’s a hairy problem with a lot of edge cases and sometimes I’m just not that smart.

So be heard with your vote (for this feature or any other!)

tags: ruby, rubyonrails

I’m not big on publicizing commercial works due to the obvious bias involved, but we’ve recently finished up the Oxford American College Dictionary and Thesaurus for the iPhone and our client was nice enough to give us a few free download codes. Never one to waste free stuff I thought I’d offer them up to my readers.

So here’s the deal – to distribute these free downloads of our Oxford Dictionary for the iPhone (appstore) I’m going to run a little contest: Post your favorite word in the comments along with your preferred usage of the word (like an example sentence). I’ll pick my favorite five entries after a week or so and will email you your promo codes (so be sure to leave your email address in the comment form). Note: I am a sucker for humor and wit, so be liberal in your application of them.

Most real iPhone dictionaries (from respected publications) go for upwards of $20 – $30 so this is a pretty decent value.

Now wow me with your vocabulary.

You guys should be getting your promo codes in a few minutes. Thanks for the submissions everybody! (and, yes, all these words are in the dictionary app)

tags: iPhone, dictionary