Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Change to the way conflicting routes work #4164

Closed
calvincorreli opened this Issue · 8 comments

5 participants

@calvincorreli

If I have the following in my routes.rb

  resources :models
  match 'special' => 'model#new', :as => :new_model

then in 3.1, new_model_path would return

/special

but now it returns

/models/new

If you reverse their order, it now returns

/special

but that is a change in behavior from 3.1.

//Lars

@calvincorreli

Btw, set up a fresh Rails 3.2 project exhibiting this problem here:

https://github.com/larspind/rails-3-2-routes-priority-change

//Lars

@drogus
Collaborator

Leaving compatibility issue apart, is it correct behavior in case of 3.1? Routes that are higher have higher priority, so maybe it should be true also for url helpers?

@calvincorreli

The argument can be made both ways.

I can certainly see the logic in the pre-3.2 way.

The router searches from the top when looking for a match.

But since the routing helpers are merely methods, it's logical that a method defined further down in the source overrides a method defined higher up.

//Lars

@drogus
Collaborator

@larspind sure, if you look at it from ruby side, it's correct behavior. But how many times you want to have higher priority routes with lower priority helpers? I would say that it's the opposite most of the time. Probably it was not brought up before because conflicting routes are not a common pattern in most apps.

@tenderlove tenderlove was assigned
@tenderlove
Owner

@drogus I agree that this is wrong behavior in 3.1. On the router recognition side, the rule is: first match wins. It seems inconsistent that on generation side the rule would be "last declared wins".

I will try to fix this for compatibility sake, but the behavior will definitely be removed for Rails 4. I want generation and recognition to have consistent rules.

@drogus
Collaborator

@tenderlove cool, I like the idea, I would also not break it for 3.2, 4.0 seems good

@tenderlove tenderlove closed this issue from a commit
@tenderlove tenderlove last named route wins. fixes #4164
This differs from route recognition where first recognized route wins.
This will not be supported in Rails 4.0 so that route recognition and
generation rules are consistent.
50af25b
@andyjeffries

I think we need to rethink how this works (maybe with an optional parameter of priority to say how important this overwrite is). My situation (which is why 71d769e was committed) is that we have an app made up of reusable gems (with minimal glue code) to be able to quickly build complex websites. However, some clients want URLs overwritten (for SEO, translation, whatever) so we have a named route in the gem (which everything links to) and we want to be able to put a route in the application routes table to override that named route.

This was described in #3861 and it was agreed with and merged.

We need this functionality back as our customer (large) won't let us launch the site with these URLs, so what are our options? Is this code just in journey (in which case we can fork it)? Here's the pull request/commit to Journey rails/journey#4

@wkj wkj referenced this issue from a commit
@tenderlove tenderlove When generating routes, the last defined named route wins. This is in
contrast to route recognition where the first recognized route wins.
This behavior will not exist in Rails 4.0.

See:

  #4245
  #4164
63f7a61
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.