--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3cb36c11-16ee-4702-92a3-f9afb177bbca%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALMtK1FqpfeGvGC8c6P66CppXqfaS0NoKYWpjX17MsdvqWVuHQ%40mail.gmail.com.
I'm also curious to learn more about this "set of decorators" that can
be applied to a view by the url resolver - that feature doesn't seem to
be documented in the linked gist or in the API example.
I am not at all sure that it is a good idea to mix layers in this
suggested way, or what specific use case it improves. If the argument
that a constraint matches is an integer, why is it (in practice) useful
for the constraint to know that this integer is supposed to be the ID of
some particular model class? Why is it good for that constraint, when
reversing, to be able to take a model instance instead of an ID? To me
this sounds like the sort of implicit type coercion that makes APIs
harder to use and understand, not easier.
1) The interplay between URL and Constraint is unclear.
2) The Resolver / View API can be simplified.
One important thing to keep in mind is reverse() performance.
I am a little less acquainted with the internals of resolving and reversing than the people above, and I must say that I have a hard time understanding your new syntax when looking at the example gist. That might also have to do with the indentation style. Would the (blog_detail, blog_index) -> blog_resolver -> patterns be the replacement of the urlpatterns below? Because I think the latter is a lot more readable.
Do you have an example of something that is easy to do with this API that is hard or impossible with the current API?
- Anssi
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3cb36c11-16ee-4702-92a3-f9afb177bbca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
from django.conf.urls import url, includefrom django.core.urls import Constraint, Resolver404
class ConstraintBase(Constraint): """ This exists purely as a way to ensure MRO mixin inheritance will work """ def match(self, path, request=None): return path, (), {}
def construct(self, url, *args, **kwargs): return url, args, kwargs
class SchemeConstraintMixin(object): scheme = ''
def match(self, path, request=None): if request and request.scheme == self.scheme: return super(SchemeConstraintMixin, self).match(path, request) raise Resolver404()
def construct(self, url, *args, **kwargs): url.scheme = self.scheme return super(SchemeConstraintMixin, self).construct(url, *args, **kwargs)
class HostConstraintMixin(object): host = ''
def match(self, path, request=None): if request and request.get_host() == self.host: return super(HostConstraintMixin, self).match(path, request) raise Resolver404()
def construct(self, url, *args, **kwargs): url.host = self.host return super(HostConstraintMixin, self).construct(url, *args, **kwargs)
class SchemeHostConstraint(SchemeConstraintMixin, HostConstraintMixin, ConstraintBase): def __init__(self, scheme, host): self.scheme = scheme self.host = host
www_constraint = SchemeHostConstraint('http', 'localhost:8000')my_constraint = SchemeHostConstraint('https', 'my.example.com')
urlpatterns = [ url(www_constraint, include([ url(r'^$', 'testviews.views.testview', {'template': 'testview1.html'}, 'testview1'), url(r'^test2/$', 'testviews.views.testview', {'template': 'testview2.html'}, 'testview2') ])), url(my_constraint, include([ url(r'^test3/$', 'testviews.views.testview', {'template': 'testview3.html'}, 'testview3'), url(r'^test4/$', 'testviews.views.testview', {'template': 'testview3.html'}, 'testview4') ]))]
Major bug: the `request` object needs to be passed into `resolve()` here: https://github.com/knbk/django/blob/4a9d2a05bb76c9ad996921b9efadd8dad877540e/django/core/handlers/base.py#L134 - otherwise host and scheme constraints cannot work. I believe there are other instances of `resolve()` not getting `request`, but mostly in tests. Is there a way for `request` to be a required parameter instead of defaulting to `None`?
Minor bug: Given two subdomains, my.example.com and localhost:8000, going to a url using the 'localhost:8000' subdomain that only exists on the 'my' subdomain (ie. http://my.example.com/test3/ exists, but you try to go to http://localhost:8000/test3/), the debug mode 'patterns tried list' is a series of blank lines. See image below:
Nice to have: When attempting to use multiple constraints (ie. list or tuple of constraints), using `RegexPattern` seems to be required when doing pattern matching - otherwise it messes up while calling `construct`. First glance says this is by design? I think it would be nice to still be able to use the old r'<regex here>' (without wrapping in `RegexPattern`) syntax as well. Not critical, as the multi-constraints is NOT breaking behaviour, just new.
Nice to have: I realise this isn't likely to happen at all, but it would be nice if when `reverse()` and `{% url %}` are called, it would be good to be able to automatically drop the scheme and host when reconstituting an absolute URL if the scheme and host of the current request match. However, I'm pretty sure that this is not possible, given the various scenarios in which these methods can be called. Obviously, this is not required, as the resulting URL (with scheme/host or without when matching) will still work regardless!
Marten, did you consider putting the new API in `django.urls` instead of `django.core.urls`? I don't need there's a need to namespace it under "core", but others might be able to confirm the philosophy behind this.
+100 for django.urls. resolving and reversing functions should be located in the same namespace.
M
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a8174a99-2364-4e52-9368-320e94810c62%40googlegroups.com.