Opened 16 years ago

Last modified 12 years ago

#8264 new New feature

Replace get_absolute_url with more sane alternative

Reported by: simon Owned by: simon
Component: Core (URLs) Version: dev
Severity: Normal Keywords:
Cc: semente@…, jdunck@…, dd+djangoproject@…, ognajd@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Change History (11)

comment:1 by Jacob, 16 years ago

Triage Stage: UnreviewedDesign decision needed

comment:2 by , 16 years ago

Great summary Simon!

+1 on not being forced to use the sites framework. There should be a domain setting for the easy (99% of the time!) case of a single site. The sites framework should also be an opt-in thing rather than opt-out once this works :)

comment:3 by Daniel Pope <dan@…>, 16 years ago

Under the two cases you mention for using a URL, you say:

  1. The full URL, including protocol and domain.
  2. The path component of the URL. This is needed for internal links - it's a waste of bytes to jam the full URL in a regular link when a path could be used instead.

The second case is for internal links, yes, but in some cases internal links might have to be full URLs. I don't have practical experience with multi-site set-ups in Django, but I think we need to allow for them.

If you accept that the requirements can be stated as

  1. A method for getting an absolute URL
  2. A method for getting an internal link (aka relative URL) that is correct for any URL within the current site but preferably as short as possible
  3. Resources may reside on different domains, or be linked to with a different URL scheme (eg. https://, but also webcal://, feed://)

then the corollaries are:

  1. (from 2, 3) the internal link may be an absolute URL
  2. (from 3) you have to check the scheme and domain match when converting an absolute URL to a URL path
  3. (from a) you have to use urlparse.urljoin to compute the absolute URL from the internal link
  4. (from a) get_url_path would be a misnomer as we can't constrain it to a path

There are other cases where we might want to convert a relative URL to an absolute URL too, incidentally, so that should not be exclusively tied up with models. (As an aside, one such case is in HttpResponseRedirect: according to RFC2616 §14.30 the Location: header is defined as requiring an absolute URL, though that's never been enforced by UAs).

I often wish Python had a url type equivalent to Java's java.net.URL. When I programmed in Java I found it very neatly reinforced the semantics that a link cannot be used as a URL and cannot be concatenated onto a URL. It's like Python's unicode type: it makes sure you do the right thing with character sets. Our current URL handling would be akin to trying to use UTF-8-encoded bytestrings throughout. So, if performance isn't a problem, a utility class like that would be great.

One other point: I don't want to be forced to specify a base URL for simple, self-contained sites, because that makes it annoying to move sites between domains. It would be handy if I could set the site's base URL to None and then work simply with relative URLs, but I would see an exception if ever I tried to get an absolute URL.

comment:4 by Guilherme Gondim <semente@…>, 16 years ago

Cc: semente@… added

comment:5 by (none), 16 years ago

milestone: post-1.0

Milestone post-1.0 deleted

comment:6 by Jeremy Dunck, 16 years ago

Cc: jdunck@… added

comment:7 by davedash, 15 years ago

Cc: dd+djangoproject@… added

comment:8 by Luke Plant, 14 years ago

Severity: Normal
Type: New feature

comment:9 by Aymeric Augustin, 13 years ago

Easy pickings: unset
Triage Stage: Design decision neededAccepted
UI/UX: unset

I'm accepting this ticket because get_absolute_url could certainly be improved. If someone wants to work on this, please send a proposal to django-developers.

comment:10 by Daniel Sokolowski, 12 years ago

Cc: ognajd@… added

comment:11 by Aymeric Augustin, 12 years ago

Component: Core (Other)Core (URLs)
Note: See TracTickets for help on using tickets.
Back to Top