Rails Ruby on Rails → 2.x

Comments and changes to this ticket

• You flagged this item as spam.
  

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

  1) -- patch introduces error_messages_on

• 

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

  • no changes were found...

  • 0001-Introduce-error_messages_on-helper.-Unlike-error_m.patch 19.9 KB

• You flagged this item as spam.
  

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

  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?

• You flagged this item as spam.
  

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

  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.

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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 March 23rd, 2009 @ 11:14 AM

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

• You flagged this item as spam.
  

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

• You flagged this item as spam.
  

  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 (@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é 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!

• You flagged this item as spam.
  

  Yaroslav Markin April 10th, 2010 @ 04:05 PM

  @José Is there any chance https://rails.lighthouseapp.com/projects/8994/tickets/1484/a/65757/... can be applied to dynamic_form?

• 

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

  If you rebase I can apply.

• You flagged this item as spam.
  

  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://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!

• 

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

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

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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!

• You flagged this item as spam.
  

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

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

• You flagged this item as spam.
  

  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?

• You flagged this item as spam.
  

  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?

• You flagged this item as spam.
  

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