Finally, it was merged. You can read about how to use it on https://cowbell-labs.com/2015-01-22-active-model-errors-details.html
W dniu czwartek, 8 stycznia 2015 16:59:37 UTC+1 użytkownik Tsyren napisał: > > Seems nice, +1 vote for that. > > Thanks > Tsyren > > On Sun, Jan 4, 2015 at 10:31 AM, Szymon Nowak <szi...@gmail.com > <javascript:>> 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/rail >>>>>> s/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-co...@googlegroups.com <javascript:>. >> To post to this group, send email to rubyonra...@googlegroups.com >> <javascript:>. >> 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.
