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
>>> <https://github.com/jazzband/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+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/613aacf1-95de-43ac-8cc6-a54c09e22aca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
