Mostly you should use the _path flavor. If you need to spec the host or
protocol (like for talking to another app or service), then use the _url
flavor.
Mostly you should use the _path flavor. If you need to spec the host or
protocol (like for talking to another app or service), then use the _url
flavor.
Usually the rule is _path in views, _url in controller (where you
mostly use it together with redirect_to).
Mostly you should use the _path flavor. If you need to spec the host or
protocol (like for talking to another app or service), then use the _url
flavor.
Usually the rule is _path in views, _url in controller (where you
mostly use it together with redirect_to).
and what about to use everytime url?
(i think that the DHH’s reply will be: “you’re insaaaane”… )
David [or anyone], would you mind explaining why you wouldn’t want to
use
the _path form in a controller. I’ve never done it but I don’t
understand
why it’s bad form. Thanks.
Mostly you should use the _path flavor. If you need to spec the host or
protocol (like for talking to another app or service), then use the _url
flavor.
I guess a case could be made, though, that for REST compliance, you’d
want to use _url throughout, as _path doesn’t give you a unique
identifier that can be used to locate a resource outside of this
particular browser session.
I guess a case could be made, though, that for REST compliance, you’d
want to use _url throughout, as _path doesn’t give you a unique
identifier that can be used to locate a resource outside of this
particular browser session.
I’m not sure I follow? *_path are for views because ahrefs are
implicitly linked to the current URL. So it’d be a waste of bytes to
repeat it over and over.
In the controller, though, *_url is needed for redirect_to because the
HTTP specification mandates that the Location: header in 3xx redirects
is a complete URL.
I guess a case could be made, though, that for REST compliance, you’d
want to use _url throughout, as _path doesn’t give you a unique
identifier that can be used to locate a resource outside of this
particular browser session.
I’m not sure I follow? *_path are for views because ahrefs are
implicitly linked to the current URL. So it’d be a waste of bytes to
repeat it over and over.
I’m overstating it (didn’t mean to dismiss all relative URLs –
just thinking out loud about a case where the hyperlinks in a response
might be needed to identify resources but the response not contain the
necessary base URL identification. I’m not coming up with any great
sample scenarios, though.
Mostly you should use the _path flavor. If you need to spec the host or
protocol (like for talking to another app or service), then use the _url
flavor.
Usually the rule is _path in views, _url in controller (where you
mostly use it together with redirect_to).
I’m getting an error when trying to use a resource_url helper inside my
controller to render a view.
I guess a case could be made, though, that for REST compliance, you’d
want to use _url throughout, as _path doesn’t give you a unique
identifier that can be used to locate a resource outside of this
particular browser session.
I’m not sure I follow? *_path are for views because ahrefs are
implicitly linked to the current URL. So it’d be a waste of bytes to
repeat it over and over.
This thread is old but still shows up in top rank in search engines.
Here is my advise: use _url all the time. Yeah it wastes a few bytes,
but the day you’ll add https support to your site it will save you tons
of headaches. Same applies to images that will end up in RSS feeds.
Using _path would give them a feed:// protocol.
So save yourself troubles and use _url all the time, period.
Here is my advise: use _url all the time. Yeah it wastes a few bytes,
but the day you’ll add https support to your site it will save you tons
of headaches.
How would it save headaches in case of https?.
Lets say you have apache in front of your rails server and only apache
is configured for https. And http is disabled in apache.
Now with _url option, the web page gets generated as
<form ... action="http://host/resource/1" ...
And apache passes it along as it as, unless one enables URL rewriting in
apache to replace http with https.
Where as if it is just _path it gets generated as
<form ...action="/resource/1" ...
This form submission works irrespective of how(http or https) apache is
configured.
So the earlier recommendation ( i.e., use _path in views _url in
specific use cases) is still a better one compared to use _url in all
cases. (no period )
Here’s a reason where I wish I was using _url everywhere.
I’ve switched my site to almost all ssl except for a google map page
which needs to be in non-ssl ($10,000 for the ssl version). On that
page (just like every other page) are about 15-20 navigation links that
should point to https/ssl pages even though the map page itself is http.
I wish I wouldn’t have to go through and change all those links to point
to https using _url. I could instead use ssl_requirement and specify
all pages should be ssl except for my map page, but I think I’d rather
make all 15-20 links of navigation use the _url instead and force https
to avoid an unneeded redirect/latency. I actually have redirects in
apache conf file instead of using ssl_requirement, but same idea…why
redirect when you can specify _url and have less latency?
If you have a solution for me that would relieve my need to have _url
for all my navigation due to the one http map page, please, let me know.
Kevin
Madhav V. wrote in post #969656:
How would it save headaches in case of https?.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.