Replacing get_absolute_url, I am against it
drozzy
http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl
and personally I think adding two functions get_url_path and get_url
is a lot more confusing. One can never remember which one gets the
Absolute url and which one gets the Relative url.
If it is going to be done I propose adding another function, and thus
have two possible functions on the model:
get_relative_url
get_absolute_url
However I am not sure how that will tie into the Permalink decorator:
http://docs.djangoproject.com/en/dev/ref/models/instances/#the-permalink-decorator
Waylan Limberg
>
> Just read the "Replacing get_absolute_url proposal":
> http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl
>
> and personally I think adding two functions get_url_path and get_url
> is a lot more confusing. One can never remember which one gets the
> Absolute url and which one gets the Relative url.
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.
> If it is going to be done I propose adding another function, and thus
> have two possible functions on the model:
> get_relative_url
> get_absolute_url
That seems like the obvious solution except that get_absolute_url
currently returns a url path. Oops! With the change, everyone's
existing code will suddenly break. The only way to fix it is to
depreciate get_absolute_url and create new names for the replacements.
Oh, and this reference to relative urls. Relative to what? The site
root? The app root? The currently viewed page? "get_relative_url" is
probably not what you actually want. "get_url_path" is.
Of course, this all really a bikeshed issue. Generally, 'he who builds
the shed gets to paint it.'
--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
Ivan Sagalaev
> If it is going to be done I propose adding another function, and thus
> have two possible functions on the model:
> get_relative_url
> get_absolute_url
get_relative_url is rather misleading. The proper meaning of "relative"
is a url relative to current url: "./some/hierarchy", "some/", ".". Put
simply it's a path that doesn't start with a slash. The problem is that
on the model layer no notion of a current url exists so this makes
get_relative_url even more weird.
Thomas K. Adamcik
>
> 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
Zachary Voase
You can include as much information in a URL as you like, and it's a
subclass of unicode, so it can be used directly in templates, HTTP
clients, et cetera.
You can do stuff like URLObject(host='hostname', path='/foo/bar/'), or
URLObject.parse('http://mysite.com/path/to/somewhere/').
It could be a solution. Do what you will with it.
--
Zack
Jacob Kaplan-Moss
> In essence we could add only one new method to the API that returns a
> URL-object that provides access to the data:
I like this idea a lot. It solves most of the problems I have with
get_absolute_url:
* I dislike the name -- far too verbose. Why not just `obj.url()`?
* I wish there was a better mechanism for getting host-relative URLs,
schema-relative URLs, etc. The `<a href="//...">` trick is annoyingly
obscure.
* The mismatch between `@models.permalink` and `get_absolute_url` is
very counter-intuitive.
* The fact that the returned URL is a string often means I end up
doing something like `obj.get_absolute_url().split('/')`. Objects are
better.
> 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.
Python's already got such an object; it's `urlparse.ParseResult` (the
object returned by `urlparse.urlparse`. We'd need a tiny subclass with
a backwards-compatible `__str__`, but that's about it.
> 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.
I'm +1 on this proposal; please ping me if you work up a patch and
I'll take a look.
Jacob
Zachary Voase
something. Sorry about that, that's 36 hours worth of sleep
deprivation for you :)
OK, so I think I've roughed together an idea of how you might use
URLObject in url() methods (or get_url(), or __url__(), et cetera).
You can see this here [1]. I'd appreciate any comments or suggestions.
One of the major advantages of URLObject is that it directly
subclasses unicode, so you can use it everywhere strings are used, but
it still has those handy methods and properties for manipulating/
querying the URL.
--
Zack
[1]: http://pastry.se/110066/
On Sep 12, 2:20 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
>
> > In essence we could add only one new method to the API that returns a
> > URL-object that provides access to the data:
>
> I like this idea a lot. It solves most of the problems I have with
> get_absolute_url:
>
> * I dislike the name -- far too verbose. Why not just `obj.url()`?
> * I wish there was a better mechanism for getting host-relative URLs,
> schema-relative URLs, etc. The `<a href="//...">` trick is annoyingly
> obscure.
> * The fact that the returned URL is a string often means I end up
> doing something like `obj.get_absolute_url().split('/')`. Objects are
> better.
>
> > 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.
>
> Python's already got such an object; it's `urlparse.ParseResult` (the
> object returned by `urlparse.urlparse`. We'd need a tiny subclass with
> a backwards-compatible `__str__`, but that's about it.
>
> > I have not double checked if all the issues mentioned in
matehat
> subclasses unicode, so you can use it everywhere strings are used, but
> it still has those handy methods and properties for manipulating/
> querying the URL.
really good idea in that it can be completely transparent in situation
where we just need to work on a bare unicode path. More
straightforward than doing `unicode(model.url)`.
I also agree that the "subclassing urlparse.ParseResult" idea would
make the jump deadly simple.
Still, I think I'm +1 for Zachary's idea.
Ivan Sagalaev
> * The fact that the returned URL is a string often means I end up
> doing something like `obj.get_absolute_url().split('/')`. Objects are
> better.
I kind of disagree with the last sentence here. An object in place of a
well-known native type (here, str) adds another abstraction to grok for
a newbie. It's like when you read WinAPI docs and see a function
accepting structs of structs of structs and changing some memory buffer
but you only have a string and want to get an int. I mean it boils down
to it anyway, just not obvious from the start...
In the rare cases when I do need to split a URL into parts I just use
urlsplit:
schema, domain, path, query, fragment = urlsplit(obj.url())
I believe it's a well-known pattern for an experienced pythoneer.
So I'm against of introducing a new Django-specific way of doing
urlsplit that has chances to confuse both newbies and gurus for
different reasons.
Ivan Sagalaev
> In the rare cases when I do need to split a URL into parts I just use
> urlsplit:
>
> schema, domain, path, query, fragment = urlsplit(obj.url())
Oh... And for template authors we could just make 5 filters returning
those parts:
{{ obj.url|domain }}
Jacob Kaplan-Moss
<man...@softwaremaniacs.org> wrote:
>> In the rare cases when I do need to split a URL into parts I just use
>> urlsplit:
>>
>> schema, domain, path, query, fragment = urlsplit(obj.url())
That's not in any way intitutive for a new user in the way that
`obj.url().schema` is.
> Oh... And for template authors we could just make 5 filters returning
> those parts:
>
> {{ obj.url|domain }}
So we need *five* new built-in filters instead of `{{ obj.url.domain
}}`? Why? What if I want to access the username or password? Do we
"just" add two more filters?
Ugh.
Jacob
Ivan Sagalaev
>>> schema, domain, path, query, fragment = urlsplit(obj.url())
>
> That's not in any way intitutive for a new user in the way that
> `obj.url().schema` is.
After thinking of it a bit more I agree about new users. My main concern
though was about not using an established pattern.
>> Oh... And for template authors we could just make 5 filters returning
>> those parts:
>>
>> {{ obj.url|domain }}
>
> So we need *five* new built-in filters instead of `{{ obj.url.domain
> }}`? Why? What if I want to access the username or password? Do we
> "just" add two more filters?
Looks like I shouldn't have posted that follow-up :-). It was only an
afterthought. Actually I think we don't need even those 5 filters
because there are no clear use cases for all of them. If we need schema-
and host-relative URLs then we need exactly two filters:
{{ obj.url|schema-relative }} (or better "protocol-relative")
{{ obj.url|host-relative }}
I think it's better than, say:
//{{ obj.url.domain }}{{ obj.url.path }}?{{ obj.url.query }}
The filter is also useful for {% url %}-generated URLs using {% filter
%}. Which I believe is not doable with url-as-an-object thing.
Thoughts?
Zachary Voase
unicode, can be used *directly* within the template and it'll render
out to the URL without any magic.
In addition, you can ensure that the URLObject is host-relative by
doing `url.without_host()` (or {{ url.without_host }} in a template).
That'll produce http:///path/foo/bar/ URLs; for schema-relativity too
just do url.without_host().without_schema(). It’s ugly but it works.
You could also implement a HTTP-specific convenience wrapper (i.e.
url.relative()).
If you want to determine whether a URLObject is host-relative, just
use {% if url.host %} from the template. Again, you might want to add
a simple is_relative() convenience method.
--
Zack
Ivan Sagalaev
> If you take a look, you’ll notice that URLObject, being a subclass of
> unicode, can be used *directly* within the template and it'll render
> out to the URL without any magic.
Beware! Using the word "magic" too loosely may infuriate certain core
devs and they will start hunting you all over the globe, or worse,
strike you out of a Christmas present list for this year!
Honestly, having an object that looks like unicode but at the same time
able to be /-ed or |-ed with another unicode in my dictionary *is*
called "magic".
I still fail to see why this clever micro-DSL is needed when all this
can be done with normal Python and be more clear.
Zachary Voase
defining __str__() or __unicode__() on it, why not just use a unicode
subclass?
And the micro-DSL is 100% optional. All of the operator overrides are
aliases to other methods, with the exception of __and__() and __or__
(), which are tiny wrappers over add_query_param() and set_query_param
() respectively.
--
Zack
Yuri Baburov
I'm very much concerned about using get_absolute_url and its substitutes at all.
This approach makes harder to keep apps modular, extensible and
reusable of apps.
1) You make a hypothesis that each object instance has a single point
of reverse and a default output format, giving you only one fixed url
for object. What about i18n? Different output formats?
2) You want to make model instances to know their own url, that's
misleading. Why one needs urlconf then?
3) Cause you can't easily override model method get_absolute_url, you
introduce ABSOLUTE_URL_OVERRIDES hook.
And you now want that model instances to know the site they are displayed on?!
What about same object displayed on multiple sites & internationalized urls?
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
drozzy
returned by the model.
It does not have to be about the object. It can be: google.com.
Whatever!
All the things you are concerned with can be created using urls+views
so you shouldn't even need to worry about get_absolute_url.
I think you guys took it overboard with all the URL-class stuff. Like
the case for Yuri shows, once you start creating URL class you will
have to make all sorts of exceptions and additions for stuff that
people need.
Yuri Baburov
>
> get_absolute_url is just a shortcut for one stupid thing: Get some url
> returned by the model.
> It does not have to be about the object. It can be: google.com.
> Whatever!
What it does it do in django core then?
If it's just some user-level method for some random stuff.
> All the things you are concerned with can be created using urls+views
> so you shouldn't even need to worry about get_absolute_url.
I don't worry, unless anyone will make (3rd party) module with
get_absolute_url in one way and someone else to make another module
with another usage of get_absolute_url.
Unless some 3rd-party module creator will expect any specific behavior
from other modules.
Just get_absolute_url doesn't play well with django-plugin-federation.
It takes also 3 pages in docs, that promote this bad method usage
among the django beginners.
Say, imagine django.contrib.comments will use get_absolute_url to
promote current site and blog post, which has current comment, but not
taking care that user needs content in his chosen language, not any
fixed one, and that language is a part of an url.
I.e. say you are rendering "last comments" block.
This link shouldn't be neither rendered with Comment.get_absolute_url
nor Post.get_absolute_url nor Site.get_absolute_url cause of i18n and
multisite issues (let's imagine user is looking at
german-language-flavoured version of the page):
http://tag.blogsite.com/intl/de/2009/08/get-absolute-url-is-bad-practice/#comment241
(though see http://docs.djangoproject.com/en/dev/ref/settings/#absolute-url-overrides
for this bad practice documented)
P.S. yes, if comments were paginated, situation was even more dramatic!
> I think you guys took it overboard with all the URL-class stuff. Like
> the case for Yuri shows, once you start creating URL class you will
> have to make all sorts of exceptions and additions for stuff that
> people need.
--
Jacob Kaplan-Moss
Ya know, this conversation is going in circles, and arguing over
increasingly trivial details. As always, our policy is that the person
who builds the bikeshed gets to decide which color it is, so I'd
suggest we all stop writing email and start writing Python now. Work
up a patch, and then let's discuss from there.
Jacob
Yuri Baburov
how about my kind of patch -- deprecation and removal of the feature? :)
--
Patrick J McNerthney
I am with you.
I am new to Django and am deep in the middle of my first major project
using Django. When I encountered get_absolute_url, my reaction was,
"What were they thinking!". Why does the model have any knowledge about
it's presentation? What if that very same model object is used for two
completely separate purposes in two different applications?
Then I realized that this method is mainly used by the Admin application
as a convenience method for creating that nice little "View on site"
link. Now that finally made some sense in terms of what they were
thinking. get_absolute_url is a nice little parlor trick for the Admin
application, that then got subverted for inappropriate uses.
In our main application, it has been mandated not to use
get_absolute_url ever. We have in place a mechanism to allow the view
layers to generate a url for a given object.
+1 for deprecating.
Pat McNerthney
ClearPoint Metrics, Inc.
James Bennett
<pmcne...@clearpointmetrics.com> wrote:
> I am new to Django and am deep in the middle of my first major project
> using Django. When I encountered get_absolute_url, my reaction was,
> "What were they thinking!". Why does the model have any knowledge about
> it's presentation? What if that very same model object is used for two
> completely separate purposes in two different applications?
Then you'd want something more complicated to handle that. But,
really, "where does this object live" is a question the object itself
ought to be able to answer. One can argue endlessly about the name,
API, return values, etc., etc., but the fact remains that there's a
valid problem whose valid solution is "ask the object". And so, like
Jacob, I'd really like to start seeing actual *code* to try to improve
the way that gets done, rather than the endless bikeshedding this
thread seems to be headed for.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
David Larlet
Le 12 sept. 2009 à 15:20, Jacob Kaplan-Moss a écrit :
>
> On Sat, Sep 12, 2009 at 8:42 AM, Thomas K. Adamcik
> <tada...@gmail.com> wrote:
>> In essence we could add only one new method to the API that returns a
>> URL-object that provides access to the data:
>
> I like this idea a lot. It solves most of the problems I have with
> get_absolute_url:
>
> * I dislike the name -- far too verbose. Why not just `obj.url()`?
Note this option will break a lot of models with an existing url field
(that's just a warning, as a devil's advocate, I'm not fond of the
current name too...).
Regards,
David
Yuri Baburov
It's MVC pattern you're trying to overcome with this sort of question.
Model is not living anywhere on site!
Admin app instance ("View" and "Controller") is one that allows you to
manage specific model instances ("Model") and make guesses what's the
meaning of these models.
Admin app should have that get_object_url for the link "View on site"
if it needs to show that.
(Usually, it can use reverse for that).
You can subclass ModelAdmin to override get_object_url behaviour.
You can't override models easily without monkeypatching (subclassing
makes new model or you deal with model proxies only to override
get_object_url), that's why ABSOLUTE_URL_OVERRIDES hook was born.
Patrick J McNerthney
bike shed, we are discussing the fact that the bike shed is being built
in entirely the wrong location. IMO, the proper place to build this
particular bike shed is in the urlresolvers section of the city, not in
the models section.
Just like urlresolvers right now has a "reverse" method that can take in
a view name, a similar method should be exposed that takes in a object.
Something like:
urlresolvers.reverse_for_object(object)
In addition, most, if not all, of the current optional reverse arguments
probably should be supported.
Obviously, there are a few details to work out with regards to how to
nicely configure the url resolvers sub-system to support this, but I
believe that is where the bike shed belongs.
Pat McNerthney
ClearPoint Metrics, Inc.
Alex Gaynor
<pmcne...@clearpointmetrics.com> wrote:
>
> We are not (at least not now), endless discussing the color to paint the
> bike shed, we are discussing the fact that the bike shed is being built
> in entirely the wrong location. IMO, the proper place to build this
> particular bike shed is in the urlresolvers section of the city, not in
> the models section.
>
> Just like urlresolvers right now has a "reverse" method that can take in
> a view name, a similar method should be exposed that takes in a object.
> Something like:
>
> urlresolvers.reverse_for_object(object)
>
> In addition, most, if not all, of the current optional reverse arguments
> probably should be supported.
>
> Obviously, there are a few details to work out with regards to how to
> nicely configure the url resolvers sub-system to support this, but I
> believe that is where the bike shed belongs.
>
system know about Models more acceptable than having the Model system
know about URLs? This is most certainly a bike shed IMO.
Alex
> Pat McNerthney
> ClearPoint Metrics, Inc.
>
> Yuri Baburov wrote:
>> This is kind of incorrect question by itself.
>> It's MVC pattern you're trying to overcome with this sort of question.
>>
>> Model is not living anywhere on site!
>> Admin app instance ("View" and "Controller") is one that allows you to
>> manage specific model instances ("Model") and make guesses what's the
>> meaning of these models.
>> Admin app should have that get_object_url for the link "View on site"
>> if it needs to show that.
>> (Usually, it can use reverse for that).
>> You can subclass ModelAdmin to override get_object_url behaviour.
>> You can't override models easily without monkeypatching (subclassing
>> makes new model or you deal with model proxies only to override
>> get_object_url), that's why ABSOLUTE_URL_OVERRIDES hook was born.
>>
>>
>
>
> >
>
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
Patrick J McNerthney
> If the objective is to seperate the two systems why is having the URL
> system know about Models more acceptable than having the Model system
> know about URLs? This is most certainly a bike shed IMO.
>
the "Controller" in the MVC world, and need to know about both the
models and the views. It is the "glue" that binds the two together.
URLs already do know about models and that will remain.
It is having models know about what URLs that is a circular dependency
that is both unneeded and problematic. Models should stand alone and be
usable by any number of applications within the same project. Having
the models be responsible for knowing how they are being presented does
not allow for unanticipated uses of those models.
I'll leave it at that for now if you still think it is merely the
repainting of the bike shed.
James Bennett
<pmcne...@clearpointmetrics.com> wrote:
> The objective is not to completely separate the two. URLs are roughly
> the "Controller" in the MVC world, and need to know about both the
> models and the views. It is the "glue" that binds the two together.
> URLs already do know about models and that will remain.
Except I can't help thinking this is an awfully arbitrary distinction
to draw. In effect you're saying that nearly every question about an
object should be answerable by interrogating it directly, *except* for
"what's a URL I can use for you?"
That's such a common question that I really think it needs to have an
answer which doesn't involve hunting over multiple layers of the
stack.
> It is having models know about what URLs that is a circular dependency
> that is both unneeded and problematic. Models should stand alone and be
> usable by any number of applications within the same project. Having
> the models be responsible for knowing how they are being presented does
> not allow for unanticipated uses of those models.
Keep in mind that the recommended practice is for get_absolute_url()
to work with reverse() and friends, rather than hard-code information
directly. Having it supply a pattern name and some arguments offers
quite a lot of flexibility with no need to monkeypatch anything, and
is why I've consistently harped on this technique in various talks on
effective reuse of Django applications.
Ivan Sagalaev
> Except I can't help thinking this is an awfully arbitrary distinction
> to draw. In effect you're saying that nearly every question about an
> object should be answerable by interrogating it directly, *except* for
> "what's a URL I can use for you?"
May be I can explain this distinction with an example.
We once had two different web sites about "events". They both had a
"core" set of models but each one had their own set of views & urls. So
for a core Event model a question "what's your URL" just didn't make
sense. It had two different URLs depending on the project it was
imported in.
That said, I do see a value in having a default URL (and a default
__unicode__ for that matter) simply because it's useful in many (or even
majority?) of real-world cases.
So Yuri, Patrick, this method is optional so there's not technical need
to deprecate it. This discussion really is about how it should be done,
not if.
matehat
directly to models can be made relatively independent from the models
themselves. I do so personally by using the "permalink" decorator and
returning just a name for the right view to be matched, using the
built-in named view mechanism. So you can have just a little
information about the view that should be requested, hardcoded in your
models, thus easily share models across projects, just as long as the
name used to identify the view is explicit enough about its use to not
throw ambiguities in.
Kevin Teague
> If the objective is to seperate the two systems why is having the URL
> system know about Models more acceptable than having the Model system
> know about URLs? This is most certainly a bike shed IMO.
>
> Alex
the web, not the models making an URL system.
In Grok to get an URL for a model we do:
view.url(model)
Which is as it should be.
At my work we often work with model objects from the command-line, so
having URL stuff in the models would just be cruft. More importantly,
it keeps the dependencies clean. The package that contains the models
only declares that it depends upon SQL Alchemy. Slip a model.url() in
there, and now you've got to declare a dependency on an URL system and
most likely you're going to have to pull in a whole web stack just to
use those models. :(
Simon Willison
> James Bennett wrote:
> > Except I can't help thinking this is an awfully arbitrary distinction
> > to draw. In effect you're saying that nearly every question about an
> > object should be answerable by interrogating it directly, *except* for
> > "what's a URL I can use for you?"
>
> May be I can explain this distinction with an example.
>
> We once had two different web sites about "events". They both had a
> "core" set of models but each one had their own set of views & urls. So
> for a core Event model a question "what's your URL" just didn't make
> sense. It had two different URLs depending on the project it was
> imported in.
From a purity point of view, having models that know what their URLs
are when Django's concept of a URL is defined in the urls.py file is
an obvious violation of separation of concerns.
From a pragmatism point of view, being able to ask an object it's URL
is incredibly convenient - and in 90% of the projects I've worked on
in the past few years each object has had one and only one URL (in
fact REST principles actively encourage this).
I'm OK with .get_url() and .get_url_path() (I still prefer the
semantics and names used in my original proposal to any of the
proposed alternatives) only being useful 90% of the times, with
projects where objects can have more than one URL needing to find some
alternative method.
As for running code, allow me to point to http://code.google.com/p/django-urls/
:)
Cheers,
Simon
Daniel Sokolowski
On Saturday, 12 September 2009 07:42:40 UTC-4, adamcik wrote:
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
Russell Keith-Magee
Would anyone know if there is still any momentum behind this? I like Adamcik's approach.