This project is archived and is in readonly mode.

#5360 ✓stale
Deleted User

Allow Model to supply arguments to url_for in polymorphic_routes

Reported by Deleted User | August 11th, 2010 @ 09:53 PM

when using a model for a url_for

url_for <model_instance>

when using a model for a nested resource

url_for [<enclosing_model_instance>,<nested_model_instance>]

which is ugly, and breaks things.. like respond_with, form_for, etc..


url_for <nested_model_instance>

the challenge being making url_for send the right arguments to the named_route_path method.


Have the method define a polymorphic_route_args method, to provide the appropriate arguments to the named route helper method.

so the model now looks like ...

class NestedModel
  belongs_to :containing_model
  def polymorphic_url_args

Comments and changes to this ticket

  • Rolf Bjaanes

    Rolf Bjaanes August 11th, 2010 @ 10:59 PM

    Seems a bit ambiguous to me.

    You don't always want to link to the resource as a nested resource.
    Oftentimes you link to it as just a resource, think shallow routes.

    And what if it belongs to many?

    If you need url_for to be simpler than it is, make a helper for yourself.

    def nested_url_for(nested_instance)
    url_for(nested_instance.parent, nested_instance) end

    or something along those lines.

  • Rolf Bjaanes

    Rolf Bjaanes August 11th, 2010 @ 11:11 PM

    Could you give some details on the breakage of form_for and respond_with?
    You do know you can pretty much always use [@instance, @nested_instance] without url_for?

  • Deleted User

    Deleted User August 12th, 2010 @ 12:25 AM

    [@instance, @nested_instance] isn't working in my case however..

    I have to explicitly call nested_controller_path(@instance, @nested_instance

    relevant route...

    resources :foo do 
      resources :bar, :controller => :foo_bar

    I either get a undefined method foo_foo_bar_path'<br/> or, it can't find the route..

    Pre 3.0 I handled this by writing foo_foo_bar_path helpers, however this no-longer works. and I really don't like having to write [@instance, @nested_instance] everywhere, when a simple @instance should do the job..

  • Rolf Bjaanes

    Rolf Bjaanes August 12th, 2010 @ 02:32 PM

    I see what you are getting at, but it quickly becomes ambiguous and inflexible.

    Say I have one "Document" and I want to link to this,
    but it belongs to two or more "VirtualDirectories",
    how would it know which VirtualDirectory to use as parent?

    Use rake routes to see available routes.
    (:controller doesn't change the name of the route, so in your example the route helper would be foo_bar_path)

    My suggestion is that if you need this feature, make a gem/plugin and use it in your own apps.
    Share and develop it with people who would like this feature through github or similiar.

  • Deleted User

    Deleted User August 12th, 2010 @ 04:59 PM

    As for having the routes become ambiguous, and inflexible. ...

    If you ever wanted to have two routes for the the same model without nesting ( say for having admin and .. the url_for instance will always default to one of them, and for the other you will have to use the path or url helpers.. Is that also not just as ambiguous, and inflexible? Using the url_for , supplies the default_route, it's not going to prevent you from supplying something else using a helper method if you have another path available.

    It is opinionated, however, being opinionated is one of the foundational concepts behind rails in the first place. It simply allows you to specify a replacement for <nested_instance> with the appropriate [<container(id)>,<instance(id)>], and to not repeat yourself in the hundreds of places where it needs it throughout your application.

    The patch itself simply provides the optional hook to allow you to specify the arguments for the default route when rails otherwise would get confused.. allowing you to extend the convention of url_for being able to find the route for a bare instance record ( and by extension, all of the methods that rely on url_for ) even for the otherwise awkward case of nested or other cases where finding the path would be confusing for url_for.

    It doesn't prevent you from being more explicit when specifying the route otherwise, and it doesn't break existing functionality.

  • Rolf Bjaanes

    Rolf Bjaanes August 12th, 2010 @ 06:49 PM

    Seems like there is little interest to weigh in from others.

    I can see the use case, but I wouldn't do it this way.
    Would have made a helper to help me out with the duplication.

    For later: Add tests when creating a patch

    -1 on the feature from me. Sorry.

  • Andrea Campi

    Andrea Campi October 16th, 2010 @ 11:13 PM

    -1 from me too, this belongs in a gem.

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:30 PM

    • State changed from “new” to “open”

    This issue has been automatically marked as stale because it has not been commented on for at least three months.

    The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

    Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:30 PM

    • State changed from “open” to “stale”

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>

People watching this ticket