Got burned by two things today in one of my apps by upgrading to Rails 3.1. The first thing was a few nested forms stopped working when editing an existing record that had child records. None of the children were getting rendered. For briefity, the form basically was like:

<%= form_for @meal do |meal_form| %>
      <% meal_form.fields_for :meal_items do |item_form| %>
        <%= render :partial => 'meal_item_fields',
                   :locals => { :f => item_form } %>
      <% end %>
<% end %>

Can you spot the error? Once I spotted it I felt rather dumb myself. It’s the following erb tag

<% meal_form.fields_for :meal_items do |item_form| %>

Ya even when they’re nested you HAVE to use the <%= form... doh!

<%= meal_form.fields_for :meal_items do |item_form| %>

The second problem I ran into, and which I still don't have an answer for, though if you do answer my StackOverflow question. Basically, in Rails 2.3 if you needed to get at an instance of the Template Builder you could use @template, but then they changed it in Rails 3 to a special method called "view_context". Far enough, so I was using view_context in Rails 3.0.X to create nested forms (other than the one above) dynamically using jQuery ajax and js.erb partials. Using view_context allowed me to call fields_for off of it so that I would get nicely named form_fields when I didn't have the parent FormBuilder handy. Like this

In some_view.js.erb

<% fields =
    view_context.fields_for :meal_items, do |f|
      render :partial => 'meal_item_fields', :locals => {:f => f}
    end %>

$("#meal-items").append("<%= escape_javascript(fields) %>");

But once I upgrade to 3.1, I started getting the following error

ActionView::Template::Error (undefined local variable or method `view_context' for #<#:0x1057b9f70>):

Perhaps this was removed as the Core team figured, why do you need the view_context available when you're in a view template already... but I don't know. I was able to workaround it though by moving my code up into the controller. Which does seem to be a violation of the MVC separation, but I couldn't find any other way to make it work like pre Rails upgrade. So instead of creating a local variable "fields", this became an instance variable that was set in the controller action. And render needed to become render_to_string with an html_safe call tacked on the end.

In controller

def some_ajax_action
  @fields =
    view_context.fields_for :meal_items, do |f|
      render_to_string(:partial => 'fields', :locals => {:f => f}).html_safe

I don't like this, but it'll do for now I suppose. And now in some_view.js.erb

$("#meal-items").append("<%= escape_javascript(@fields) %>");


Splitting Rails DOM ids with RegEx Look Aheads

by Irish on October 15, 2010

In my Rails erb views I make good use of the dom_id view helper method. It basically introspects the object you pass to it and creates a unique id to use in your markup, based on the object type and database id. So for example if I had a Post with id 1, I could do:

    2 <li id="<%= dom_id(@post) %>">

And it would be rendered as

    2 <li id="post_1">

This is fine until you use dom_id on an object with a compound name like EmailNotification. Now dom_id will create a unique id like


Which is still good until I’m doing some front-end testing and I’m parsing these dom ids to find their related db records. Now I need to split “email_notification_1″ in a way that easily separates the object class from the identifier. How would you do that?

Well, what we can do here is use an advanced Regular Expression feature called a negative look ahead. We want to say, “split the string on the last underscore”.

A negative look ahead uses the ?! syntax in parenthesis, everything that follows ?! in the parenthesis will be used in the negative look ahead matching. So in our case we want to say, there should be a underscore that can be followed by any character except another underscore. The pattern would like like this:


We can confirm in irb

$ ree-1.8.7-head > x = "email_notification_1234"
=> "email_notification_1234"
ree-1.8.7-head > klass, id = x.split(/_(?!.*_)/)
=> ["email_notification", "1234"]

Likewise, If we wanted to split the dom_id on the first underscore we could just use a regular look ahead. It is similar but uses the ?= syntax.

$ ree-1.8.7-head > x.split(/_(?=.*_)/)
=> ["email", "notification_1234"]

{ 1 comment }

On a project I’m currently working on, we use ActiveRecord callbacks heavily. From simplying creating other associated objects, to recording the historic activity about the object in question, and more.

The drawback I find from the scope of AR callbacks though is that you only have direct access to data from the database. And since you can’t pass arguments to a AR callback, you can’t easily get the request params for example or know which controller action fired off the the AR chain that triggered the callback you’re in, or know who the current user logged in is.

But it turns out that there is a way, however it is neither straight forward or obvious. Say for example you have the following model and controller:

    1 class Post < ActiveRecord::Base
    2   belongs_to :user
    3   belongs_to :group
    4   has_one    :alert, :as => 'alertable'
    6   after_update :note_activity
    8   private
    9   def note_activity
   10     group.admins.each do |admin|
   11       # What user is doing this update?
   12       admin.notifications.create(:user => "Someone",
   13                                  :action => 'did something')
   14     end
   15   end
   16 end
    1 class Admin::PostsController < ApplicationController
    3   def update
    4     @post = Post.find(params[:id])
    6     if @post.update_attributes(params[:post])
    7       redirect_to admin_posts_path
    8     else
    9       render :action => 'edit'
   10     end
   11   end
   12 end

What we want to accomplish here is that all admins of a group get a notification when another admin user edits a post. The post in question here has no context in it’s callback of which admin was logged in at the time the update happened. So what we’re gonna do is put the admin user’s id onto the current thread of the request in a before filter. Then, we’ll pull that id off in the callback to look up the admin and create the notifications.

So we’ll add a simple before filter:

    1 class ApplicationController < ActionController::Base
    2   before_filter :store_user
    4   def store_user
    5     User.current = current_user
    6   end
    7 end

And create a couple class methods on User to store the currently logged in admin for the duration of the request:

    1 class User < ActiveRecord::Base
    3   def self.current=(user)
    4     Thread.current['user'] = user.try(:id)
    5   end
    7   def self.current
    8     @@current ||= User.find_by_id(Thread.current['user'])
    9   end
   10 end

Now we can alter our note_activity method in Post to get the admin who did the edit:

    1 def note_activity
    2   group.admins.each do |admin|
    3     admin.notifications.create(:user => User.current,
    4                                :action => 'did something')
    5   end
    6 end

This works well in my project. I’d like to know if there is a less “hacky” way of doing this but I’m not currently aware of one.

Need web application development, maintenance for your existing app, or a third party code review?

Velocity Labs can help.

Click here to get started!