Deprecate error_messages_for

1) -- patch introduces error_messages_on

2) regarding flash messages translation:

http://pastie.org/324812

Questions:

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

Here's my take: http://pastie.org/324815

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.

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.

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.

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 flash.now 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.

Hi Ryan,

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

I do think flash (@flash.now@, 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: http://rubyforge.org/projects/cu.... 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é Is there any chance https://rails.lighthouseapp.com/projects/8994/tickets/1484/a/65757/... can be applied to dynamic_form?

If you rebase I can apply.

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://github.com/rails/dynamic_form.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!

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

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.

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!

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

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?

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?

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...