"wrap" argument for django.conf.urls.defaults.url to decorate views more easily

[Charlie DeTar]

The ​documention for cacheing recommends a method for using cache decorators in the urlconf, which is a natural way to do page-based cacheing. However, most urlconfs of any complexity use string representations of views (and perhaps also the "prefix" feature of patterns()). To decorate the views, one would have to import them all explicitly and then apply the wrapper functions, which is cumbersome.

The attached patch addresses this by adding a "wrap" function to url(), which specifies a function or list of functions with which to "decorate" the view. For includes, the wrap argument applies to all included URLs. It can be used like this:

urlpatterns = patterns('myapp.views',
    url(r'^pattern/$', 'viewfunc', wrap=mydecorator),
    url(r'^pattern2/$', include('otherapp.urls'), wrap=[mydecorator1, mydecorator2]),
)

This can provide a natural way to add cacheing or any other decoration (such as login_required) both to individual views, or to all the views within an include.

[Charlie DeTar]

New feature: wrap kwarg for "url" to decorate views.

[Etienne Robillard]

hm, what is the advantage of using a wrap keyword argument? i don't see any, at first glance,
especially when include is being used. worse, it seems not explicit to define a wrap, but rather
somewhat implicit.. i'd stick with standard decorators and not add any more overhead in url routing
hooks...

[Charlie DeTar]

Two advantages:

1. You can use it even when you define the view function as a string. Basically, this is a side effect of Django already having some magic to resolve strings into view functions. Django has this magic, presumably, for two reasons -- so you can reduce typing by including a prefix in your patterns() call when all the view functions are from the same module, and to make it unnecessary to explicitly import all the different views you might reference in a urlconf, which might become cumbersome.

2. You can apply a decorator to all of the views in an "include". Thus, you can apply the decorators (things like cacheing and login_required) to URLs defined in a reusable app, or for whole portions of an application or site. This reduces duplication of your decorators, and allows decorating the functionality of other people's code that you may not want to have to modify.

As the Django documentation I linked to in the summary indicates, the URLconf can be a natural place to include decorators for things like cacheing, and allows you to avoid coupling cacheing with your view definition. However, if you define views in patterns() using strings, you can't decorate them. I would argue the URLconf is also a natural place to include decorators for things like logon_required as well, especially in the context of reusable apps whose URLconf I might want to include, but which I don't want to have to modify.

This will help keep "site" oriented notions like cacheing and permissions distinct from "app" oriented view logic, and to help keep definitions of these things DRY.

[Florian Sening]

New feature: wrap kwarg for "url" to decorate views. (usable with trunk)

[Florian Sening]

I'm not sure if a wrap argument is the way to go but there really needs to be an easy way to do this.

Currently I'm using Marty Alchin's CurrentUserMiddleware as a decorator - effectively applying it to the whole admin. His original approach was to use a small lambda wrapper function. Since admin.site.root was replaced by admin.site.urls a different approach is needed.

Btw: I just added a version of the original patch that works with trunk.

[Aymeric Augustin]

Another use case is to apply the atomic decorator to a group of views.

I think the concept is useful, but I'm not convinced by the proposed API. url() lines are often long and wrap would be buried at the end.

I'd like to see an API more targeted towards groups of URLs, ie. something at the level of patterns or include rather than at the level of url.

Using strings rather than the view objects themselves in URLconfs is annoying, because it delays errors and complicates debugging. I don't mind if the API doesn't improve this use case. Importing the view explicitly and wrapping in in a decorator is a better idea.

[Bas Peschier]

patterns and dotted string urls are now deprecated, which invalidates the main focus of the ticket as described.

Though I can see the use case of wrapping groups of urls as aaugustin described, pushing view functionality (decorators) through include which just builds up the urlconf strikes me as inappropriate (what about includes inside the included urlconf for example?).