Snippet List
Use :
`@group_required(('toto', 'titi'))`
`def my_view(request):`
`...`
`@group_required('toto')`
`def my_view(request):`
`...`
Note that group_required() also takes an optional login_url parameter
`@group_required('toto', login_url='/loginpage/')`
`def my_view(request):`
`...`
As in the login_required() decorator, login_url defaults to settings.LOGIN_URL.
If the raise_exception parameter is given, the decorator will raise PermissionDenied, prompting the 403 (HTTP Forbidden) view instead of redirecting to the login page.
Such as https://docs.djangoproject.com/en/1.8/topics/auth/default/#the-permission-required-decorator
**Inspired by** : https://github.com/django/django/blob/stable/1.8.x/django/contrib/auth/decorators.py
- decorator
- login
- auth
- decorators
- group_required
- @group_required
Long story short:
* Django lets you call functions in templates, but you can't pass any parameters.
* Sometimes you need to use the request object to perform certain tasks, such as determining whether the current user has permission to do something.
* The recommended approach is to call functions that require parameters in the view, and then pass the results as variables in the context. This sometimes feels a bit overkill.
* Creating a templatetag to call any function with any parameter will definitely break the intention for not letting functions to be called with parameters in templates.
* So, what if we could tell django to inject the request into certain functions? That's what this decorator is for.
For instance, suppose you have a model:
class SomeModel(models.Model):
...
def current_user_can_do_something(self, request):
...some logic here using request...
You could use the decorator like this:
class SomeModel(models.Model):
...
@inject_request
def current_user_can_do_something(self, request=None):
...some logic here using request...
And in the template go straight to:
{{ somemodel_instance.current_user_can_do_something }}
So that the decorator would perform some operations to find the request in the frame tree and inject it if found. The assertions are intented to make sure things will work even if the request cannot be found, so that the coder may program defensively.
- templates
- request
- decorators
This file includes two Django view decorators `header` and `headers` that provide an easy way to set response headers.
Also, because I have to work with a lot of cross domain requests, I include few shortcuts for convenience to set the Access-Control-Allow-Origin header appropriately.
- views
- view
- decorator
- headers
- decorators
- header
A decorator to add a GUID Field to a Django Model. There are other bits of code out there that do similar things, but it was important for the field to have a unique value _before_ it is saved in the database. The contribute_to_class method therefore registers the field class with the post_init signal of the class it's being added to. The handler for that signal is where field initialization is done.
Sometimes I don't want to reveal a staff-only view so I created this decorator, using ``django.contrib.admin.views.decorators.staff_member_required`` as my boilerplate. Non staff members are kicked to the 404 curb.
Suggestion: Create a file, ``decorators.py`` in your project (or single app) and import like so: ``from myproject.app_name.decorators import staff_or_404``.
- user
- auth
- decorators
- staff
A very simple decorator that caches both on-class and in memcached:
@method_cache(3600)
def some_intensive_method(self):
return # do intensive stuff`
Alternatively, if you just want to keep it per request and forgo memcaching, just do:
@method_cache()
def some_intensive_method(self):
return # do intensive stuff`
- memcache
- cache
- decorator
- memcached
- decorators
- caching
Decorator for views that need confirmation page. For example, delete
object view. Decorated view renders confirmation page defined by template
'template_name'. If request.POST contains confirmation key, defined
by 'key' parameter, then original view is executed.
Context for confirmation page is created by function 'context_creator',
which accepts same arguments as decorated view.
- views
- decorators
- confirmation
A decorator that allows the programmer to restrict access to some views only to non logged-in users. For instance, if an user in logged in, it should be denied access to views like /accounts/register or /accounts/login.
This trick is for caching a view only if it passes some condition, for example, if there are more than zero items in a list. The same methodology could be used for conditional applying of other decorators.
A slight modification (and, I think, improvement) of the URL decorator found in [snippet 395](http://www.djangosnippets.org/snippets/395/).
What's different between this snippet and 395?
1. We use `django.conf.urls.defaults.url()` when adding patterns
2. We support arbitrary arguments to the `url()` method (like `name="foo"`)
3. We _do not_ support multiple url patterns (this didn't seem useful to me, but if it is I can add it back.)
- urls
- url
- decorator
- decorators
- urlpatterns
Checks if the request is an AJAX request, if not it returns an HttpResponseNotFound. It looks for the XMLHttpRequest value in the HTTP_X_REQUESTED_WITH header. Major javascript frameworks (jQuery, etc.) send this header in every AJAX request.
- ajax
- decorator
- decorators
- xmlhttprequest
- ajax-required
One thing I wanted for a while was the ability to basically apply something like @login_required to a bunch of urlpatterns in one go, instead of having to decorate each and every view manually.
In this example, the latter two views will always raise a 404.
- urls
- views
- decorators
- urlpatterns
This takes advantage of a recently added feature to django, being able to give it real functions as the view instead of having it be a string that is has to look up itself.
It takes advantage of how decorators work and how `cache_control` works, normally you'd do something like this:
@cache_control(private=True, public=False)
def view_stuff(request):
# ...
return response
Which is equal to doing `view_stuff = cache_control(private=True, public=False)(view_stuff)` after definition. `cache_control` is a function factory, more or less, which we use to our advantage.
15 snippets posted so far.