#8264: Replace get_absolute_url with more sane alternative
-----------------------------+------------------------------------
Reporter: simon | Owner: simon
Type: New feature | Status: new
Component: Core (URLs) | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Changes (by Carlton Gibson):
* cc: Carlton Gibson (added)
Comment:
I hate to take an 18 year old ticket and say let's WONTFIX it, but I think
we should WONTFIX this.
There are two bits in the proposal. One is the name, `get_absolute_url()`.
I think changing it at this point is not worth the price of admission. OK,
it's not strictly a full URL because it's missing scheme and domain, but
it serves for one for internal purposes, and it is absolute for the site
(starting with `/`), rather than relative. (Would we say it's a "path-
absolute relative URL"? — That's a mouthful.) Anyhow I think we should
just live with it after all these years.
The second part is that ''missing scheme and domain''.
The standard way to handle this in the request-response cycle is with
[https://docs.djangoproject.com/en/6.0/ref/request-
response/#django.http.HttpRequest.build_absolute_uri
HttpRequest.build_absolute_uri], like so:
{{{
def my_view(request):
bookmark = Bookmarks.objects.get(id=1)
path = bookmark.get_absolute_url() # /bookmarks/1/
full_url = request.build_absolute_uri(path)
...
}}}
Outside the request-response cycle, Django cannot know the current
scheme/domain unless we provide it.
We **might** use the sites framework:
{{{
from django.contrib.sites.models import Site
site = Site.objects.get_current()
full_url = f"https://{site.domain}/bookmarks/1/";
}}}
Denpending on the sites framework being installed and `settings.SITE_ID`
being configured.
I think more and more people are **not** using the sites framework. (Us
leaning into it now would likely be us going against the current.)
In reality I think most folks are declaring a setting like:
{{{
# settings.py
SITE_URL = "https://example.com";
}}}
And then building a full URLs like:
{{{
from django.conf import settings
path = "/bookmarks/1/"
full_url = f"{settings.SITE_URL}{path}"
}}}
Such a setting is easily configured per-environment. It's pretty simple.
Users tend to know, in context, whether they need a full URL with scheme
and domain or whether the ''path-absolute relative URL'' is sufficient.
That this has sat here so long unfixed strongly implies to me that
anything more complex, to automatically handle that difference, really
isn't needed.
--
Ticket URL: <https://code.djangoproject.com/ticket/8264#comment:14>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019e2c1a9b72-3317ceee-be5b-4cd6-b586-dd5e64ebacb0-000000%40eu-central-1.amazonses.com.
