Thanks Marc& Shai for taking the time to look at this. Apologies for the late response as I was busy.
Yes, I agree that decorators can be used to tag urls, however I think that the way that the URL rework code applies decorators can be improved. The reason I've called the decorators approach 'heavyweight' is because the decorators are applied by the ResolverMatch object and so all of the decorator code (not just the decorated function) will run for every decorator for every request. Normally decorator code (if applied directly to the view) would only run at module import time and only the wrapped function code is executed during a request and there is no reason to look at performance. But placing all the functools wrapping helper code into the 'hot' request path should be avoided if possible. I've gone over the URL rework branch in some detail and I think we can/should move the application of decorators from inside the ResolverMatch to the ResolverEndpoint so that the decorators are applied only once when the resolver is instantiated using get_resolver(). I'm happy to submit a patch for that however I'm not entirely sure which tree is the reference one for the URL rework. Is it this one? https://github.com/jaddison/django/tree/gsoc2015_url_dispatcher Atul On 29 September 2015 at 07:06, Shai Berger <s...@platonix.com> wrote: > Assume decorators, then, more or less: > > def tagged(*tags): > def decorate(view): > @functools.wraps(view) > def decorated(*args, **kw): > view(*args, **kw) > decorated.tags = tags > return decorated > return decorate > > (taking care to define a new function in the decorator so that you can use > the > same view with differnet tags in different URLs) > > That doesn't seem too heavyweight to me. Am I missing something? > > Assuming not, the decorator defined above can be used already with current > production versions of Django for single URLs, and after the URL rework > also > on includes. > > Your examples become > > # Already today > api_v1_patterns = [ > url(r'^list/books/$', views.list_books, name='list-books'), > url(r'^list/articles/$', tagged('public')(views.list_articles), > name='list-articles'), > ... > ] > > # After URL rework > urlpatterns = [ > url(r'^$', views.home, name='home'), > url(r'^private/$', include(private_patterns), > decorators=[tagged('private')]), > url(r'^api/1/', include(api_v1_patterns), decorators=[ > tagged('api', 'private', 'jsonp'), > ]), > url(r'^api/2/', include(api_v1_patterns), decorators=[ > tagged('api', 'cors', 'private'), > ]), > ] > > taking Marc's doubts (which I agree with) into account, and seeing as 1.9 > is > already feature-frozen, I think that the proper way forward for this > feature > is to live out of core. > > If I am missing something, and it is hard to implement it out of core, > please > explain. > > HTH, > Shai. > > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHdnYztTtpNK6uWv3cw12Cocj1GWzMwQyPKa0hzuo8JqZ22Uig%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
