What do you think about using numbers for error codes? For example on ios side errors may have message (description) and code (among other things). On Sun, Jan 4, 2015 at 7:24 AM pathé Sene <pathe.s...@gmail.com> wrote:
> +1 > > 2015-01-02 14:33 GMT+00:00 Jason Fleetwood-Boldt <t...@datatravels.com>: > >> >> +1 for separation of concerns >> >> >> >> On Jan 1, 2015, at 5:26 PM, Szymon Nowak <szi...@gmail.com> wrote: >> >> 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. >> >> >> ---- >> >> Jason Fleetwood-Boldt >> t...@datatravels.com >> http://www.jasonfleetwoodboldt.com/writing >> >> All material © Jason Fleetwood-Boldt 2014. Public conversations may be >> turned into blog posts (original poster information will be made >> anonymous). Email ja...@datatravels.com with questions/concerns about >> this. >> >> -- >> 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. >> > > -- > 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. > -- 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.
