Since general consensus is that this PR is not the best idea in the world
I'm closing it along with corresponding issue on Trac.
On Fri, Nov 11, 2016 at 1:00 PM, Florian Apolloner
wrote:
> Hi Jannis,
>
> this is very much in line with what I would like to see as outcome of DEP
> 201. If you mana
Hi Jannis,
this is very much in line with what I would like to see as outcome of DEP
201. If you manage to find some time, I'd very much like to see your
input/guidance on the DEP (given your hands on experience with
django-hosts)!
Cheers,
Florian
On Friday, November 11, 2016 at 11:14:27 AM U
On Friday, November 11, 2016 at 9:15:30 AM UTC+1, Mislav Cimperšak wrote:
>
> The original PR is just a simple addition (that is still backwards
> compatible) to the `reverse` method; how people choose to use it (and when)
> is up to them.
>
This still does not makes it a good addition, especi
On Friday, November 11, 2016 at 10:16:32 AM UTC+1, Marc Tamlyn wrote:
>
> Given we already have `request.build_absolute_uri(path)`, I'm not 100%
> sure what extra this gives us. It's a bit of syntactic sugar for sure, but
> it solves a pretty narrow use case. The only times I've actually needed
Hi all,
Full disclosure: I’m one of the authors of django-hosts. But I’ve thought about
this problem a lot and maybe that’s useful for this discussion, maybe not :)
# Passing the request to reverse
I'm not convinced that reverse should be directly passed the request to build a
full URL since i
Given we already have `request.build_absolute_uri(path)`, I'm not 100% sure
what extra this gives us. It's a bit of syntactic sugar for sure, but it
solves a pretty narrow use case. The only times I've actually needed this
has been when sending emails and I'm using a `Site` object instead of
reques
Thinking about url tag and threadlocals is a step in the wrong direction.
The original PR is just a simple addition (that is still backwards
compatible) to the `reverse` method; how people choose to use it (and when)
is up to them. Adding something to the `url` tag is almost bound to brake
somethi
On Saturday, November 5, 2016 at 6:56:29 PM UTC+1, Sjoerd Job Postmus wrote:
>
> If you go with storing the base domain in the threadlocals, why not go
> full in and store the request itself in the locals? [1]
>
Because that opens a whole new can of worms, if possible we want less
threadlocals,
If you go with storing the base domain in the threadlocals, why not go full in and store the request itself in the locals? [1]
As far as using it in the templates... We have a RequestContext right? So in most cases that should not be an issue I presume.
But yes, Celery would be a problem, unless we
What I was trying to suggest is that the base domain gets stored in one of
our threadlocals so that we can generate the full URL without having access
to the domain (though I just realize that this wouldn't work in the case of
celery etc :/)
On Saturday, November 5, 2016 at 5:53:49 PM UTC+1, Mi
For me use cases were callback urls sent to some 3rd party and of course -
emails.
Yeah, I wasn't thinking about url tag.
I'm not 100% sure I understand what you are suggesting.
If we choose to go down the path of using kwarg I could change this in the
`reverse` method itself. That way calling
To be honest, I think I do not really see the usecase here. I know that
sometimes it is required to generate full urls (especially in emails), but
quite often in those you do not have access to the request at all. Also,
how would this play together with the url tag? Personally I would set the
c
During the sprint in Amsterdam I created a pull request
https://github.com/django/django/pull/7484
In it I'm adding an optional argument `request` to
`django.urls.base.urls.reverse`method.
The idea is that using `request` object one can get a fully qualified URL.
The idea is taken from Django R
13 matches
Mail list logo
