> 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.
Why the symbol that matches the validation rule? I would first try a match against the symbol that represents the message (:invalid, :too_short, etc.). If it's not a symbol try matching a subclass or AR::Error, if it's not that either try matching against to_s. This way, I expect, no tests need to be rewritten, because it should be backwards compatible. Esp. if AR::Error also implements a method_missing which does to_s.send(method, arguments). "Old" statements like: f.errors.on(:name).should == "is invalid" should then still work. Which would be good because loads of plugins and existing code rely on this. Cheers, Lawrence > > > > > 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 -~----------~----~----~----~------~----~------~--~---
