This project is archived and is in readonly mode.

#1484 ✓resolved
Yaroslav Markin

Deprecate error_messages_for

Reported by Yaroslav Markin | November 26th, 2008 @ 07:20 PM | in 2.x

(based on discussion in #rails-contrib)

  1. Provide a helper to output all errors attached to object's method, not just the first one as error_message_on does.

  2. Change scaffolding: instead of f.error_messages, use helper from (1) for every field on form, provide CSS styling for it. Move validation error messages header (X errors prohibited this object...) to flash[:error] in generated controller, change default layout to output flash[:error] and not only flash[:notice]

  3. Provide I18n for generated error messages (much like is done now for error_messages_for header), enable I18n for generated notice messages ("Post was successfully created") and allow users to change translations per-controller, this way we don't need to touch generated controller code at all to change flash messages.

  4. Add a deprecation notice to error_messages_for (?)

Comments and changes to this ticket

  • Yaroslav Markin

    Yaroslav Markin November 26th, 2008 @ 07:20 PM

    1) -- patch introduces error_messages_on

  • Yaroslav Markin
  • Yaroslav Markin

    Yaroslav Markin November 26th, 2008 @ 08:46 PM

    2) regarding flash messages translation:


    1. Is everyone okay with key naming and scopes?
    2. Should we wrap translation lookup into a helper or leave it as is?
  • Damian Janowski

    Damian Janowski November 26th, 2008 @ 08:48 PM

    Here's my take:

    I don't think we need the controller name in the key. If you tweak the string, it's probably a different string. I feel we'd be using I18n to provide context-sensitive customization and that doesn't sound right.

  • Yaroslav Markin

    Yaroslav Markin November 26th, 2008 @ 09:00 PM

    Cons: string with translation looks like a mess right now :(

    Pros: flash messages are not I18nzed at the moment but they definitely should be, and we should give a hint to developers about that.

  • Yaroslav Markin

    Yaroslav Markin November 26th, 2008 @ 09:13 PM

    • Assigned user set to “DHH”

    We decided that we should do with simpliest solution possible, don't do any I18n fallbacks and don't do errors counter since it does not matter how many errors there were.

    Assigning ticket to DHH, still in progress, of course.

  • Yaroslav Markin

    Yaroslav Markin November 27th, 2008 @ 09:24 AM

    There is still one problem we didn't think about, and that is errors on :base. error_messages_for handles them just perfect, if we replace it with error_messages_on() for each attribute, there will be no errors on base output in scaffolding.

  • Pratik

    Pratik March 23rd, 2009 @ 11:14 AM

    • Assigned user changed from “DHH” to “Pratik”
  • Ryan Bates

    Ryan Bates March 23rd, 2009 @ 03:26 PM

    I missed the discussion on #rails-contrib so it's hard to see the primary motivation behind this ticket. Can you go into detail on what is being accomplished here that cannot be done currently?

    Here's a couple points.

    • Is "flash" really the best place for this? A redirect doesn't happen when there's a validation error so the flash[:error] will stick around until the next request. You can do but it still feels like the wrong place. I prefer to keep a helper method at the top.

    • Why do you want to deprecate error_messages_for? This addition provides an alternative way to display error messages, not something that is a replacement for error_messages_for.

    • One side note (sorry somewhat unrelated), I do think it is silly how the current error_message_on will sometimes return a string, and other times return an array depending on the number of errors. I do not see how this is helpful in any way because one will always need to programatically check for the type and handle it accordingly.

  • Yaroslav Markin

    Yaroslav Markin March 23rd, 2009 @ 07:57 PM

    Hi Ryan,

    First of all, this bug is unfinished and somewhat stale, I hope to get to it soon.

    I do think flash (, that is) is great (in fact, it was suggested by DHH on IRC and that is a neat idea). flash[:error] is the best way to show short errors to user — you probably use it for things like "invalid login" or "no access" anyway — so it's a great fit for "Can't save because of 2 errors" of something like that.

    The idea of the patch — I believe Rails should have very strong defaults (for generated/scaffolded code as well), and error handling with error_messages_for is not really that great right now — I say, it's ugly. There are I18n-related issues (@"#{attribute human name} #{error on attribute}"@-style error messages) that lead to hacks like this one: Actually most of the time when you need great validation errors output, you just roll your own using error_message_on.

    I think it would be great to have scaffolded forms generated with something like error_messages_on and flash messages by default; however, I'm still not really sure how to output error messages on :base.

  • José Valim

    José Valim April 10th, 2010 @ 01:03 PM

    • State changed from “new” to “resolved”
    • Assigned user changed from “Pratik” to “José Valim”

    Something similar was applied to master a few minutes ago. Sorry, I didn't know that a patch was available in Lighthouse, otherwise I would have applied it. Thanks!

  • Yaroslav Markin
  • José Valim

    José Valim April 10th, 2010 @ 08:24 PM

    If you rebase I can apply.

  • Zef Houssney

    Zef Houssney April 15th, 2010 @ 07:11 AM

    Having a problem with this plugin... not sure if this should be under a new ticket.

    I just updated to the Rails 3 beta3, received the deprecation warning, and installed the dynamic_form plugin. I'm still getting a deprecation warning, but it is now coming from the plugin itself:

    DEPRECATION WARNING: error_messages_for was removed from Rails and is now available as a plugin. Please install it with `rails plugin install git://`. (called from error_messages at /Users/zef/rails/checklists/vendor/plugins/dynamic_form/lib/action_view/helpers/dynamic_form.rb:285)

    I wish I could give more details, but can't think of anything else to add. Thanks!

  • José Valim

    José Valim April 15th, 2010 @ 07:18 AM

    The message appears when you call f.error_messages, right? Calling error_messages_for does work?

  • Zef Houssney

    Zef Houssney April 15th, 2010 @ 07:38 AM

    That's not working either, but the trace refers to my app this time:

    (called from _render_template__1754307813_2179003940_824830 at /Users/zef/rails/checklists/app/views/checklists/_form.html.erb:2)

    I've been trying to isolate it, nothing yet.

  • Zef Houssney

    Zef Houssney April 15th, 2010 @ 08:04 AM

    I created a clean rails app and found that requiring HAML causes the problem, even if it isn't being used (for instance if you use the Compass framework for SASS, which requires HAML).

    Not sure why it's happening, probably HAML's problem. I couldn't find anything obvious (to me) that causes the breakage.

    Hope this helps!

  • Jan De Poorter

    Jan De Poorter April 20th, 2010 @ 10:10 AM

    I have the same problem. It works when I disable the will_paginate plugin

  • Rajasaurus Rex

    Rajasaurus Rex April 21st, 2010 @ 01:50 AM

    The reason this (error_messages, error_messages_for, etc) isn't working with haml/will_paginate is due to loading order and deps. If you initialize this after app loads (and thereby after haml/will_paginate load), it works fine with haml.

    Is there anyway to set in a plugin's init.rb when it should be loaded?

  • Matt Conway

    Matt Conway April 21st, 2010 @ 06:01 PM

    I have the same problem - loading the authlogic gem in Gemfile causes the deprecation warning to still appear even though I have the plugin installed. This plugin seems very sensitive on load order, is there a way you can make it load itself after everything else has initialized?

  • John Postlethwait

    John Postlethwait April 30th, 2010 @ 09:42 PM

    I am getting the exact same issue at Matt with Authlogic: The plugin is installed as well as the Authlogic Gem and the plugin is not loaded...

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>


Referenced by