polymorphic_url should handle STI better

I like this a lot.

I'd like to see (1) and (2) handled. Caching will make this fast, and therefore viable. Handling only the last segment would probably produce confusion when other parts don't work. I'd also be interested to see if you could make this work against Josh's rack-mount, which will probably form the basis for the Rails 3 router.

I'm attaching this patch to the 2.x milestone since we'll need a different patch against 3.0 once Josh's router is in place.

[bulk edit]

Marking ticket as stale. If this is still an issue please leave a comment with suggested changes, creating a patch with tests, rebasing an existing patch or just confirming the issue on a latest release or master/branches.

Automatic cleanup of spam.

So, here's a commit that implements this behavior: https://github.com/svenfuchs/rails/commit/2d298f2a140cdc8388bf09ce5...

Given an array of records it will first build an array of permutations of these record's classes and superclasses (excluding ActiveRecord::Base). Then it will build a named route url generation helper from the first permutation, check if the view responds to it and if so, return the method name. If not, it will try the next permutation and so on.

The first matching permutation will be cached with a cache key that is cheaper to calculate than the whole named route helper method name. I'd expect that this implementation of build_named_route_call therefor is also slightly faster than the current one which doesn't use any caching.

Say we have:

class Site < ActiveRecord::Base; end
class Section < ActiveRecord::Base; end
class Blog < Section; end
class Content < ActiveRecord::Base; end
class Post < Content; end

Then passing [site, blog, post] will try the following permutations:

site_blog_post_url
site_blog_content_url
site_section_post_url
site_section_content_url

We're already using something like this, so this code has been extracted from a working code base.

Caching needs to be improved though. Currently we're just populating a mattr_accessor Hash on the NamedRouteCall class. This cache never gets invalidated but probably should be invalidated in development mode. I'm not sure what the best way is to accomplish this. Maybe named route helper methods should be cached on the actual route set which will be thrown away and rebuilt?

Also, the patch above applies to current 3-0-stable. I'm unclear about which branch to base this on.