An example of using it in your settings.py:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.doc.XViewMiddleware',
'util.loginmiddleware.RequireLoginMiddleware',
)
LOGIN_REQUIRED_URLS = (
r'/payment/(.*)$',
r'/accounts/home/(.*)$',
r'/accounts/edit-account/(.*)$',
)
In a nutshell this requires the user to login for any url that matches against whats listing in LOGIN_REQUIRED_URLS. The system will redirect to [LOGIN_URL](http://www.djangoproject.com/documentation/settings/#login-url)
- middleware
- authentication
- url
- login
- auth
The rationale behind this decorator is described in django-users google group.
Usage:
=== urls.py ===
urlpatterns = patterns('',
(r'^', include('apps.app1.views')),
(r'^app2', include('apps.app2.views')),
)
=== apps/app1/views/__init__.py ===
@url(r'^index/$')
def index(request):
...
@url(r'^news/$')
def news(request):
...
urlpatterns += include_urlpatterns(r'^members', 'apps.app1.views.members')
=== apps/app1/views/members.py ===
@url(r'^profile/$)
def profile(request):
....
@url(r'^secure/$)
def secure(request):
...
@url(r'^path1/$', '^path2/$') # you can specify several patterns
def multipath_view(request):
...
def helper(): # easily distinguishable - no @url!
...
Summarizing, the benefits are:
* no more creating and supporting urlpattern maps (less files, less code, more DRY)
* have the url associated with a view in-place
* easily see if a function is a view
* fully compatible with other chained decorators
- view
- url
- decorator
- urlpatterns