Seems nice, +1 vote for that. Thanks Tsyren
On Sun, Jan 4, 2015 at 10:31 AM, Szymon Nowak <szi...@gmail.com> wrote: > I don't think numbers are a good idea in this case, as symbols map nicely > to existing error codes in Rails ( > http://guides.rubyonrails.org/i18n.html#error-message-interpolation). > > My friend just created a pull request that adds error codes to AM:Errors - > https://github.com/rails/rails/pull/18322. It's backward compatible, but > methods like "<<", "[]=" etc. don't add errors to "codes" hash (however, > they never actually did work correctly, as error messages added this way > are not translated). > > It might be possible to refactor AM::Errors completely and build > "messages" based on "codes" instead of managing both of them. > > On Sunday, 4 January 2015 05:48:26 UTC+1, Almas Sapargali wrote: >> >> 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...@gmail.com> wrote: >> >>> +1 >>> >>> 2015-01-02 14:33 GMT+00:00 Jason Fleetwood-Boldt <te...@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-co...@googlegroups.com. >>>> To post to this group, send email to rubyonra...@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 >>>> te...@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-co...@googlegroups.com. >>>> To post to this group, send email to rubyonra...@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-co...@googlegroups.com. >>> To post to this group, send email to rubyonra...@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.
