I'd use direct routes: https://guides.rubyonrails.org/routing.html#direct-routes
And form_for has been deprecated for a while. Use form_with url: my_admin_article_path(@article). to_param is for the most common case. You use named/direct routes for the rest. On Friday, May 10, 2019 at 6:27:00 AM UTC-5, Romain Goyet wrote: > > Actually, you're right, there are several ways to solve this. But I think > all of them have their drawbacks. > > - The one you mentionned makes it mandatory to write > `form_for(AdminArticleDecorator.new(@article))` instead of the more > standard and shorter `form_for([:admin, @article])` > - One could also simply write a custom helper (e.g. > my_admin_article_path(@article)). Problem, this doesn't work well with > form_for (especially if the record exists or not). And you still cannot do > `form_for([:admin, @article])`. > - Overriding the base helper, and don't touch to_param > def article_path(@article) > super(@article.slug) > end > > Problems: Overriding the helpers is a bit annoying because you have to > keep loading the file they're defined in (every time the routing helpers > are normally automatically included). > > And I still think this is a routing concern, and that > ActiveRecord#to_param is a bit awkward. > > Namely, I think one should be able to write `form_for([:admin, @article])` > and `form_for(@article)` and have those routed using different ids :-) > > > Le vendredi 10 mai 2019 01:49:01 UTC+2, Rafael Mendonça França a écrit : >> >> > Problem : there's no easy solution to achieve this, because overriding >> to_param is global. >> >> Have you considered wrapping the object in a decorator that changes the >> `to_param` method to what you want? >> >> url_for(@article) >> # => /articles/2019-05-my-breaking-news >> >> url_for(AdminArticleDecorator.new(@article)) >> # => /admin/articles/12 >> >> class AdminArticleDecorator >> def initialize(article) >> @artile = article >> end >> >> def to_param(*) >> @article.id >> end >> end >> >> Rafael Mendonça França >> http://twitter.com/rafaelfranca >> https://github.com/rafaelfranca >> >> >> On Thu, May 9, 2019 at 7:29 PM Romain Goyet <romai...@numworks.com> >> wrote: >> >>> Hi everyone! >>> >>> I've been using rails for a while (since rails 2) but never had the >>> opportunity to contribute. I'd like to take this opportunity to thank all >>> contributors to Rails :) >>> >>> Anyway, I'm running into some issue with to_param. Consider the case >>> where you have a resource that you'd like to route using identifiers that >>> are *not* the :id. Currently, the recommended way to achieve that is by >>> overriding the #to_param method on the model. I think that's questionable >>> design. >>> >>> Let's consider a simple example : you want to expose the same resource >>> at two different routes. For instance, on a blog, you'd want to route >>> articles using a slug for SEO on public URLs, and using an id on the admin >>> interface because you use like to use ids internally. >>> >>> /articles/2019-05-my-breaking-news >>> /admin/articles/12 >>> >>> Problem : there's no easy solution to achieve this, because overriding >>> to_param is global. >>> >>> Suggested solution : that's actually a routing topic, so it should be >>> solve in the routing. I suggest leveraging the "param" routing option to do >>> this, and leave the Models alone :) >>> >>> routes.draw do >>> resources :articles, param: :slug >>> namespace :admin do >>> resources :articles >>> end >>> end >>> >>> Currently, this changes the name of the parameter used in the route. >>> That's a good start. But it has *no* impact on the named route helpers. >>> Namely, url_for(@article) will still use the :id, even though ":slug" >>> has been specified. >>> I suggest to also change the named route helpers to call >>> "@article.#{param}" if a routing param has been specified. >>> >>> I hope this suggestion makes sense, just let me know :-) >>> >>> -- >>> 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 rubyonra...@googlegroups.com. >>> To post to this group, send email to rubyonra...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/rubyonrails-core. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/rubyonrails-core/eac44ecb-df8d-45f2-ae8d-cb1ad04f94a1%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/rubyonrails-core/eac44ecb-df8d-45f2-ae8d-cb1ad04f94a1%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> 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 https://groups.google.com/group/rubyonrails-core. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-core/9eac87ba-d87e-4b85-954c-e4dfe9f88e98%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
