This project is archived and is in readonly mode.
polymorphic_url behaviour changed in 2.3.0 RC1
Reported by Wincent Colaiuta | February 22nd, 2009 @ 07:11 PM
In Rails 2.2.2:
polymorphic_url(model)
Produced URLs like "http://example.com/foo/12"
Now, in Rails 2.3.0 RC1, the same code will generate different URLs for the same model depending on what kind of format is being used in the current request.
This is a big problem for Atom feeds which make use of the AtomFeedHelper.
In 2.2.2, the entry links were of the form "http://example.com/foo/12".
Now in 2.3.0 RC1 they are "http://example.com/foo/12.atom", which is a different representation of the resource.
Is this behaviour change intended? If so, I fear there will be a lot of Atom feeds out there with broken (or at least unexpected) entry links.
Comments and changes to this ticket
-
Wincent Colaiuta February 22nd, 2009 @ 07:18 PM
My workaround to restore the pre-2.3.0 behaviour is to change this in the AtomFeedHelper:
@view.polymorphic_url(model)
To:
@view.polymorphic_url(model, :format => nil)
So evidently that doesn't revert to the previously established behaviour for all users of polymorphic_url(), but at least it fixes it in the place where I ran into the bug (in my Atom feeds).
-
Wincent Colaiuta February 22nd, 2009 @ 07:22 PM
Was just chatting to a friend via IM trying to explain the issue and he made a comment that reveals that people might understand what I'm saying here.
He said, "the sudden change sucks, but I have to admit I prefer the new behaviour. in your ticket, with the http://example.com/foo/12 example http://example.com/foo/12.atom for the atom feed is better IMO. still looks neat and clean, but now its format is explicit. how it should be IMO."
So to avoid any potential confusion, let me clarify:
"foo/12" gives you the HTML version of the resource
so when you click on the "read more" link in your feed reader, you are taken to the HTML page
now, with the new behaviour, you click on the link and you're taken to "foo/12.atom"
at best, you'll get an XML representation of the record (most likely not what you were expecting when you clicked "read more"!)
at worst, you won't get anything at all because the app most likely isn't set up to have atom feeds for individual records
-
Wincent Colaiuta February 23rd, 2009 @ 06:52 PM
Just found another place with related breakage in my atom.builder templates.
There is one in my app where instead of just letting the standard polymorphic_url() behaviour kick in I am actually passing in an explicit URL:
for comment in @comments feed.entry comment, :url => issue_url(@issue) + "\#comment_#{comment.id}" do |entry| ... etc
Turns out that in this context, issue_url() also generates ".atom" links by default. Even stranger, passing in an explicit :format parameter has no effect at all inside the builder template (yet it does from other places, like script/console).
So looks like the change to polymorphic_url() is really only just scratching the surface. Looks like this goes much deeper.
-
DHH February 27th, 2009 @ 01:55 PM
- Assigned user set to josh
- Milestone cleared.
Format shouldn't be inherited for named urls.
-
josh March 4th, 2009 @ 08:11 PM
- State changed from new to open
This is not just polymorphic_url. It also affects url_for. The problem is related to the optional segment implementation for formats.
-
josh March 4th, 2009 @ 08:23 PM
- no changes were found...
-
Repository March 4th, 2009 @ 08:38 PM
- State changed from open to resolved
(from [638b3b15a13c4e274cfb317c40248e9feea3bfae]) Generating routes with optional format segment does not inherit params format [#2043 state:resolved] http://github.com/rails/rails/co...
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="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
Attachments
Referenced by
- 2081 :format gets "inherited" in 2.3 Related to #2043
- 2082 named routes seem not to work with :format I suspect that the root cause of this is common with tick...
- 2082 named routes seem not to work with :format I meant to say, "common with ticket #2081 and ticket #2043".
- 2094 Resources Routing not correctly generating paths Looks like a dupe of my bug report; see ticket #2043.
- 2043 polymorphic_url behaviour changed in 2.3.0 RC1 (from [638b3b15a13c4e274cfb317c40248e9feea3bfae]) Generat...