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.
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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.
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.
--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/-rbLcdJkIpk/unsubscribe.
To unsubscribe from this group and all its topics, 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/84fc3b7a-4263-46bb-a292-e27215952e63%40googlegroups.com.
--
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/CACcAD09g-yCWw6U5WS-ykKJRG5poWnrBCEOTGFO6YrQKgCKePQ%40mail.gmail.com.
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 request.
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.
I've talked to several people on sprints in Amsterdam before submitting a PR and it sounded like a good idea to them and reassured with DRF implementation I went with it :)
To unsubscribe from this group and all its topics, 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/dc786c3e-a4e4-4038-9844-ddf37b25a807%40googlegroups.com.