Hey, It's been a while, but once again I'm working on an API-only Rails app and I have the same problem again :)
Now that Rails 4.2 has been released and work on 5.0 has started, maybe it would be a good time to change ActiveModel::Errors API, so that it would allow to return translated error messages (like it does right now) *or* error codes (e.g. :invalid, :missing) that can be translated to any language by the app that's using the API? On Wednesday, 26 September 2012 14:00:26 UTC+2, Szymon Nowak wrote: > > On Tuesday, 25 September 2012 19:26:40 UTC+2, Aaron Patterson wrote: > >> On Tue, Sep 25, 2012 at 06:39:58AM -0700, Szymon Nowak wrote: >> > There are few issues with the current ActiveModel::Errors class. >> > >> > Firstly, when an error is added to ActiveModel::Errors class via #add >> > method >> > ( >> https://github.com/rails/rails/blob/master/activemodel/lib/active_model/errors.rb#L294) >> >> >> > its translation is added. It should not be translated when being added, >> but >> > only when being read. >> > >> > The second issue is a bit bigger. We'd like to create error responses >> in >> > our API similar to GitHub: >> > >> > { >> > "message": "Validation Failed", >> > "errors": [ >> > { >> > "resource": "Issue", >> > "field": "title", >> > "code": "missing_field" >> > } >> > ] >> > } >> > >> > >> > Currently it's impossible to figure out which validations actually >> failed >> > for a given field, as AM::Errors provides only field name and >> translated >> > error message. We've got a simple workaround for this issue: >> > >> > module ActiveModel >> > class Errors >> > def error_types >> > @_error_types ||= Hash.new{|hash,k| hash[k] = []} >> > end >> > >> > def add_with_save_names(attribute, message = nil, options = {}) >> > message ||= :invalid >> > message = message.call if message.is_a?(Proc) >> > error_types[attribute] << message >> > add_without_save_names(attribute, message, options) >> > end >> > >> > alias_method_chain :add, :save_names >> > end >> > end >> > >> > >> > This solution is far from perfect, but it's relatively simple and so >> far >> > works for us. >> > >> > The best solution would be to actually build a structure similar to >> GitHub >> > response - from that structure it would be trivial to build >> #full_messages >> > and similar methods and it would provide a lot of additional info which >> > would be extremely useful for creating APIs. >> >> Seems good. Can you work on a patch and send a PR? If we can maintain >> backwards compat, I am happy. >> > > I'll make all current methods to return the same result as they do now > (even #to_json and similar methods) and use new structure only internally. > The only question is how this new structure should be accessed via > ActiveModel object - object.errors.errors? :) > > BTW. Aaron, if you have a while could you check PR about > ActionDispatch::ParamsParser (https://github.com/rails/rails/pull/7444)? > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.