> 1. Common use case. > 2. Recommended pattern we should encourage. > 3. Avoid boilerplate code. > > And that's true for a lot of other status codes, many of which already get > treatment in Rails. That treatment depends on the context, for example, > mapping ActiveRecord exception to 4xx status code is more developer-friendly > than catching the exception yourself and calling a method. For 303 it > happens to be calling a method.
What other status codes get a special method? Each additional method is something we'll have to support going forward. Something that's easy to add now, gradually becomes harder and harder to support as it picks up users and features. On the whole we're better off not adding a feature till the use case is really compelling, and I'm just not seeing that here. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
