Ruby-on-rails – Use “error_messages” in Rails 3.2? (raises “undefined method” error)

rubyruby-on-railsruby-on-rails-3ruby-on-rails-3.2

I am getting the following error in my Rails 3.2 functional tests:

ActionView::Template::Error: undefined method `error_messages' for #
<ActionView::Helpers::FormBuilder:0x007ff8ad00d3b0>

The view code that is creating the error:

<%= form_for [@camp, @program] do |f| %>
  <%= f.error_messages %> # problematic code
  <%= f.label :name %>
<% end %>

Here is the code in my controller that is calling the above view code:

render :action => "edit", :status => :bad_request

And here is the test I am running:

test "update a program with a bad request" do
  put :update, 
    :id => programs(:traditional).to_param, 
    :program => {
      :min_age => "a" 
    },
    :camp_id => camps(123).uri

  assert_response :bad_request
end

Does anyone have any insight into why this error is occurring in a Rails 3.2 app?

Thanks!

Best Answer

try the following code to iterate all errors, if any.

<%= form_for [@camp, @program] do |f| %>
   <% @program.errors.full_messages.each do |msg| %>
      <p><%= msg %></p>
   <% end %>
<%= f.label :name %>
<% end %>

Related Solutions

Ruby-on-rails – Rails hidden field undefined method ‘merge’ error

You should do:

<%= f.hidden_field :service, :value => "test" %>

hidden_field expects a hash as a second argument

Ruby-on-rails – How to use concerns in Rails 4

So I found it out by myself. It is actually a pretty simple but powerful concept. It has to do with code reuse as in the example below. Basically, the idea is to extract common and / or context specific chunks of code in order to clean up the models and avoid them getting too fat and messy.

As an example, I'll put one well known pattern, the taggable pattern:

# app/models/product.rb
class Product
  include Taggable

  ...
end

# app/models/concerns/taggable.rb
# notice that the file name has to match the module name 
# (applying Rails conventions for autoloading)
module Taggable
  extend ActiveSupport::Concern

  included do
    has_many :taggings, as: :taggable
    has_many :tags, through: :taggings

    class_attribute :tag_limit
  end

  def tags_string
    tags.map(&:name).join(', ')
  end

  def tags_string=(tag_string)
    tag_names = tag_string.to_s.split(', ')

    tag_names.each do |tag_name|
      tags.build(name: tag_name)
    end
  end

  # methods defined here are going to extend the class, not the instance of it
  module ClassMethods

    def tag_limit(value)
      self.tag_limit_value = value
    end

  end

end

So following the Product sample, you can add Taggable to any class you desire and share its functionality.

This is pretty well explained by DHH:

In Rails 4, we’re going to invite programmers to use concerns with the default app/models/concerns and app/controllers/concerns directories that are automatically part of the load path. Together with the ActiveSupport::Concern wrapper, it’s just enough support to make this light-weight factoring mechanism shine.

Best Answer

Related Solutions

Ruby-on-rails – Rails hidden field undefined method ‘merge’ error

Ruby-on-rails – How to use concerns in Rails 4

Related Topic