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 push the request object to celery as well, but I presume that makes mostly no sense except for this.
[1] I must confess I greatly prefer being explicit with passing the request around, but sometimes you suddenly need the request object 10 layers deep but nowhere in the middle. Or, you want to use the request object in your AuthenticationBackend (for security counter-measures). For instance, django-brutebuster stores the request in a threadlocal to get the IP address.
On Nov 5, 2016 5:59 PM, Florian Apolloner <f.apollo...@gmail.com> wrote:
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, Mislav Cimperšak wrote: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 `reverse('foo', kwargs={'full': True})` would return a full URL. But that opens a whole other can of issues. For example if someone already has in their code `full` as a parameter for url.
On Saturday, November 5, 2016 at 4:40:46 PM UTC+1, Florian Apolloner wrote: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 current domain on the local "urlconf" (we have one per thread) and add a "full" kwarg to reverse (and something similar to the urltag).
Cheers,
Florian
On Saturday, November 5, 2016 at 3:41:09 PM UTC+1, Mislav Cimperšak wrote: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 Rest Framework (https://github.com/tomchristie/django-rest- framework/blob/master/rest_ framework/reverse.py#L55-L59). I've talked to Tim Graham in person and he said that there are some possibilities that django-hosts will be merged into main django code base with it's own implementation of `reverse` method.To move this issue forward I need an input from core team members regarding my implementation and future plans. If necessary I'll trash my current implementation if it will just bring on more potentials problems in the future.My arguments for suggested implementation is that it's much more simple and easier for the enduser than django-hosts implementation and it's already Tom Christie approved(TM).
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/613aacf1-95de-43ac-8cc6-a54c09e22aca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/18df8e3a-79f8-4976-86c3-4779d24a4fc9%40email.android.com.
For more options, visit https://groups.google.com/d/optout.
