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 <f.apollo...@gmail.com> wrote: > 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 UTC+1, Jannis Leidel wrote: > >> 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 it removes the separation of concern between request >> parameter handling and URL reversal and therefore be a step in the wrong >> direction. Having to hand around the request on application level is >> basically a waste of CPU cycles since that information is already be known >> to Django on the URL resolver level. >> >> Of course I acknowledge that the use case of generating full URLs on >> application level exists and that there are multiple ways to achieve this >> goal. E.g. django-hosts has been designed to mimic the URL pattern system >> to follow a recognizable and well-established pattern outside of Django’s >> core, and does more than just single-host reversal. >> >> # django-hosts >> >> It allows a single Django project to respond to requests with different >> HTTP_HOST headers (e.g. docs.example.com, api.example.com, >> admin.example.com) and maps each host to different URL configurations if >> configured so in "host patterns”, conventionally defined in hosts.py next >> to a project’s urls.py. >> >> Since it was developed as a 3rd party app it obviously had to implement >> its own reverse method to take the host into account when doing the >> reversal, since the actual lookup happens with the predefined host >> patterns, while the URL path reversal happens with Django’s own reverse. It >> uses a ROOT_HOSTCONF setting to locate the host patterns (similar to >> ROOT_URL) and defaults to the host that is defined by the DEFAULT_HOST >> setting if not provided during the reversal. That way it is API-compatible >> when used via its reverse function or template tag. >> >> I wasn't around when the inclusion of django-hosts or similar ideas was >> discussed at the DuTH sprint so I’m not sure how much of django-hosts can >> and should be ported to Django. I let Tim elaborate on that. >> >> # Hosts in Django >> >> What I personally would see as the right direction is to find a common >> ground for apps like django-hosts and simpler use cases such as generating >> the full URL when reversing a URL. From a user perspective I like where the >> DEP (https://github.com/django/deps/pull/27) for simpler URL patterns >> goes, e.g. it proposes something like this: >> >> urlpatterns = [ >> path('articles/2003/', views.special_case_2003), >> path('articles/<int:year>/', views.year_archive), >> path('articles/<int:year>/<int:month>/', views.month_archive), >> path('articles/<int:year>/<int:month>/<int:day>/', >> views.article_detail), >> ] >> >> So what we could do is allow optionally wrapping some paths with a new, >> optional host function: >> >> from django.urls import path, host >> >> urlpatterns = [ >> host('blog.example.com', [ >> path('articles/2003/', views.special_case_2003, >> name='blog-special-2003'), >> path('articles/<int:year>/', views.year_archive, >> name='blog-year'), >> path('articles/<int:year>/<int:month>/', views.month_archive, >> name='blog-month'), >> path('articles/<int:year>/<int:month>/<int:day>/', >> views.article_detail, name='blog-day'), >> ], scheme='//'), >> host('api.example.com', [ >> path('v1/', include(api.urls), namespace='api'), >> ], scheme='https://') >> ] >> >> The host function adds the given host and optional scheme to each URL >> pattern so it's available in the URL resolver reverse function as an >> optional parameter when constructing the URL. Of course that also means >> that the URL resolver requires the request host when it resolves the URL >> pattern callback and not only the request path. But since that’s an >> internal API I don’t see any backward-compatibility issues with that. >> >> Both the main reverse function and the URL tag would simply get new >> parameters whether or not to return the full URL (defaulting to False for >> backward compatibility) and maybe an optional scheme parameter. All those >> would be possible calls: >> >> reverse('blog-year', kwargs={'year': 2016}) -> /articles/2016/ >> reverse('blog-year', kwargs={'year': 2016}, host=True) -> // >> blog.example.com/articles/2016/ >> reverse('blog-year', kwargs={'year': 2016}, host=True, scheme='https://') >> -> https://blog.example.com/articles/2016/ >> >> reverse('api:user-list') -> /v1/users/ >> reverse('api:user-list', host=True) -> https://api.example.com/v1/users/ >> reverse('api:user-list', host=True, scheme='//') -> // >> api.example.com/v1/users/ >> >> {% url 'blog-year' year=2016 %} -> /articles/2016/ >> {% url 'blog-year' year=2016 with host=True %} -> // >> blog.example.com/articles/2016/ >> {% url 'blog-year' year=2016 with host=True scheme='https://' %} -> >> https://blog.example.com/articles/2016/ >> >> {% url 'api:user-list' %} -> /articles/2016/ >> {% url 'api:user-list' with host=True %} -> >> https://api.example.com/v1/users/ >> {% url 'api:user-list' with host=True scheme='//' %} -> // >> api.example.com/v1/users/ >> >> Tim, does that follow your ideas about adding django-hosts like features >> to Django? >> >> Jannis >> >> >> > On 11 Nov 2016, at 09:14, Mislav Cimperšak <mislav.c...@gmail.com> >> wrote: >> > >> > 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 >> something. >> > This implementation does not brake anything regarding `url` tag and can >> stand on it's own. >> > >> > 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 :) >> > >> > On Sat, Nov 5, 2016 at 11:04 PM, Florian Apolloner <f.apo...@gmail.com> >> wrote: >> > 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, not more… >> > >> > 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. >> > >> > >> > Still leaves the question of how to nicely pass this to the url tag. >> > >> > 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. >> > >> > >> > Yeah, I didn't think that through :) >> > >> > -- >> > 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/to >> pic/django-developers/-rbLcdJkIpk/unsubscribe. >> > To unsubscribe from this group and all its topics, 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/ms >> gid/django-developers/84fc3b7a-4263-46bb-a292-e27215952e63% >> 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-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/ms >> gid/django-developers/CACcAD09g-yCWw6U5WS-ykKJRG5poWnrBCEOTG >> FO6YrQKgCKePQ%40mail.gmail.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- > 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+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/dc786c3e-a4e4-4038-9844- > ddf37b25a807%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/dc786c3e-a4e4-4038-9844-ddf37b25a807%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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/CACcAD09b%3D237azhag%2BPqZvTJiC-S4cLnmg_a06Ai9%3DiRA6Ka0A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
