On Thu, Sep 10, 2009 at 11:58:00AM -0400, Waylan Limberg wrote:
>
> Easy, get_url returns the entire url while get_url_path returns only
> the "path" portion of a url. One could imagine feature creep resulting
> in 'get_url_protocol', 'get_url_domain' etc. I wouldn't actually
> recommend those be added, but by thinking about it that way, it trains
> my brain how to parse the proposed function names.
Out of curiosity, has anyone looked at the possibility of modeling this type of
URL-handling in a similar way that we do for db.models.FieldField with respect
to the name, path and url properties?
In essence we could add only one new method to the API that returns a
URL-object that provides access to the data:
url = obj.get_url()
print url.absolute
print url.relative
print url.protocol
print url.domain
...
If reverse() and {% url %} methods are updated to use such an URL-object
backwards-compatibility can probably be persevered through a proper __str__
method on the URL-object.
IMO it feels more right to have single method that needs to know about this
stuff instead of having separate methods for all this data which in essence
is all part of the same URL complete.
I have not double checked if all the issues mentioned in
http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl can be solved with
such a scheme, but if there is interest in such a solution I'm willing to look
into this and trying out the idea either as an external project or as a patch
proposal.
--
Thomas Kongevold Adamcik
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
