Use this to display an object on a page AND be able to process a form on this page. This is just a copy of the [Django docs advice](https://docs.djangoproject.com/en/2.2/topics/class-based-views/mixins/#using-formmixin-with-detailview), but put as a reusable, standalone View.
The Mixin approach for applying permissions to CBV views suffers from 3 issues: 1. you need to read the code to see what permissions are being applied to a View 2. multiple bits of disparate code required to specify, e.g., a simple permission check 3. permissions set on a base class are overridden by permission set on sub-class, unless special care is taken Here's a nice trick, using only built-in django machinery, apply a decorator intended to decorate a django view function to a CBV view. https://docs.djangoproject.com/en/1.11/topics/class-based-views/intro/#decorating-the-class This approach works for any function decorators with arguments - simply wrap it in a function that takes the same arguments: def my_cbv_decorator(*args **kwargs): return method_decorator(a_view_function_decorator(*args, **kwargs), name='dispatch') Use your new CBV decorator to decorate View sub-classes: @my_cbv_decorator('some_parameter') class MyCBView(django.views.generic.TemplateView): pass # dispatch method for this view is now wrapped by a_view_function_decorator Note: you can also pass decorator parameter directly to method_decorator, but wrapping it up like this makes the code read nicer.
# Django AJAX Form View ### A simple example for an AJAX-powered view
qwe
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.
Clear all cache set on memcached
Generic class view to abstract out the task of serving up files from within Django. Recommended usage is to combine it with SingleObjectMixin and extend certain methods based on your particular use case. Example usage class Snippet(models.Model): name = models.CharField(max_length = 100) slug = SlugField() code = models.TextField() from django.views.generic.detail import SingleObjectMixin class DownloadSnippetView(SingleObjectMixin, DownloadView): model = Snippet use_xsendfile = False mimetype = 'application/python' def get_contents(self): return self.get_object().code def get_filename(self): return self.get_object().slug + '.py' '''
Apply the `login_required` decorator to all the handlers in a class-based view that delegate to `cls.dispatch`. Optional arguments: * redirect_field_name = `REDIRECT_FIELD_NAME` * login_url = `None` See the documentation for the [`login_required`](https://docs.djangoproject.com/en/dev/topics/auth/#the-login-required-decorator) method for more information about the keyword arguments. Usage: @LoginRequired class MyListView (ListView): ...
Provides a mixin view class that requires logged-in user.
If you're used to auto_render like I am (and think it's an awesome way to DRY code) and you want to support users with and without javascript enabled, this class is perfect. You will need to provide the format requested, either through adding "(\.format)?" at the end of the url or through some middleware, but once you've done so this class will take care of rendering through the given template for normal users, JSON or JSONP for AJAX users. From [fahhem.com](http://fahhem.com/) and [Recrec Labs](http://recreclabs.com/)
This view parses complex tag queries. It generates a list of model instances matching an expression of tags. The expression currently supports intersection, union and subtraction. Expressions can also be put in parenthesis and then combined with other expressions. The expression must be passed to this view in the tag_expression argument. In my application this is simply passed from the URL querystring. This snippet uses the django-tagging app. It assumes that tags are composed of alphanumeric characters, underscores, hyphens and spaces, but the django-tagging application allows tags with other characters, so you might either want to restrict users to using tags that only contain the above characters, or you might prefer to improve this snippet. Example: This URL http://example.com/people/?(deceased&parrot)|"Monty Python" will retrieve all people who are either deceased parrots or members of Monty Python. In the tag_expression argument: * ALL is treated as a keyword. If you happen (by some sad chance) to have a tag called ALL and want to use it in the expression, surround it in quotation marks. E.g. "ALL" * Examples: - famous -returns all instances of the model tagged with famous - famous&deceased -returns all instances of the model tagged both famous and deceased. - famous|deceased -returns all instances of the model tagged famous or deceased. - parrot-deceased -returns all alive parrots in the model. - ALL-deceased -returns all instances of the model that are not tagged deceased. - ALL -returns all instances of the model - "ALL" -returns all instances of the model that are tagged ALL - "great author"&deceased -returns all models tagged as great authors and deceased. Arguments: * request -- HTTP Request object * tag_expression -- a set expression of tags, supporting intersection, union, parenthesis and difference * app_name -- App for the model we're working on (defaults to pubman) * model_name -- Model on which to apply the set operations (defaults to Article) * view -- view to redirect to after the model instance list has been constructed * html_template -- HTML template to redirect (defaults to 'pubman/tag.html')
This is an addition to Django's cache_page decorator. I wanted to cache pages for anonymous users but not cache the same page for logged in users. There's middleware to do this at a site-wide level, and it also gives you the ability to partition anonymous users, but then you have to tell Django which pages not to cache with @never_cache.
This is a decorator which essentially replaces the decorated view with a view that always raises `Http404` (File Not Found) when `settings.DEBUG` is set to True.
The `internal_view` decorator makes a view accessible only from `INTERNAL_IPS`. Handy for exposing internal APIs.
Add it to MIDDLEWARE_CLASSES and you will get request.current_view getting values like "connection.views.index" or "django.views.static.serve" - one example usage is to show different help text based on current view name. EDIT: actually, you can use process_view middleware function where you automatically get current_view as first parameter.