Changes between Version 4 and Version 5 of ReplacingGetAbsoluteUrl

Timestamp:

Aug 12, 2008, 3:09:02 PM (16 years ago)

Author:

simon

Comment:

--

ReplacingGetAbsoluteUrl

@@ -3 +3 @@
 {{{
 #!html
-<div style="background-color: #ccc; padding: 0.3em 0.4em"><strong>Summary:</strong> get_absolute_url() is poorly defined and poorly named. It's too late to fix it for Django 1.0, but we should re-think it for Django 1.1.</div>
+<div style="background-color: #ccc; padding: 0.3em 0.4em"><strong>Summary:</strong> get_absolute_url() is poorly defined and poorly named. It's too late to fix it for Django 1.0, but we should re-think it for Django 1.1 - Simon Willison</div>
 }}}
 
@@ -80 +80 @@
  * tests/regressiontests/views/tests/generic/create_update.py
  * tests/regressiontests/views/urls.py
+
+== The solution ==
+
+I'm currently leaning towards two complementary methods:
+
+* '''get_url_path()''' - returns the URL's path component, starting at the root of the site - e.g. "/blog/2008/Aug/11/slug/"
+* '''get_url()''' - returns the full URL, including the protocol and domain - e.g. http://example.com/blog/2008/Aug/11/slug/"
+
+Users should be able to define either or both of these methods. If they define one but not the other, the default implementation of the undefined method can attempt to figure it out based on the method that IS defined. This should actually work pretty well - get_url_path() is trival to derive from get_url(), whereas for sites that only exist on one domain get_url() could simply glue that domain (defined in settings.py, or derived from SITE_ID and the sites framework) on to get_url_path().
+
+I don't think this needs to be all that complicated, and in fact the above scheme could allow us to delete a whole bunch of weird special case code scattered throughout Django.