On Fri, May 8, 2009 at 10:24 PM, Lawrence Pit <lawrence....@gmail.com>wrote:

>
> I came to the same conclusion later yesterday.. an ActiveRecord::Error
> object makes more sense yes. I was thinking of this:
>
>
>  if f.error(:name) === :too_short
>
>    = n_("Need an apple", "Need %{num} apples",
> f.error(:name).options[:count])
>
>    = _("Name is too short, must be at least %{num} characters") % {
> :num => f.error(:name)[:count] }
>
>
> so the Error object implements == and === which would match against the
> message symbol or the translated message string or an AR::Error object,
> and [] is a shortcut to .options[].


Yeah, that makes sense, although ideally I think that it should match
against something other than the message; either a symbol that represents
the actual validation rule, or maybe a subclass or AR::Error.


>
>
> If the to_s method is also implemented which basically calls
> generate_message then things should work in a backwards compatible manner.
>

That's how the code I've started writing handles it, but a fair number of
tests will need to be rewritten to see if it all works properly.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"rails-i18n" group.
To post to this group, send email to rails-i18n@googlegroups.com
To unsubscribe from this group, send email to 
rails-i18n+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/rails-i18n?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to