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.
**CancelMixin** A simple mixin to use with ```generic.CreateView``` and ```generic.UpdateView``` view form templates to effortlessly implement a "Cancel" button. This smart mixin will add a URL to your context, ```{{ cancel_url }}```, that can be used as a cancel link in your form template. If no referrer URL is provided, the cancel button will link to ```default_cancel_url```, which can be overridden by view. ** **
PreviewMixin adds a preview page for Django's CBV (FormView, UpdateView, CreateView). After a form has been submitted, it is returned again, optionally in a different template to confirm. If the form is submitted with the same data, the default "form_valid" function is executed. Features: 1. `process_preview` - function executed after submitting the form for the first time (default is to do nothing) 2. `done` - function for the action if the confirm page is sent (defaults to whatever form_valid of the django cbv does) 3. `preview_template_name` - variable with the name of the template for the confirm page (defaults to taking the same template as for the initial form) 4. new function `security_hash` to calculate a hash which is added to the confirmation form. Works kind of like django-formtools, just as a Mixin for the default Django cbv.
Mixin to support pagination when randomizing querysets. Requirements: Postgres, Django Sessions Note: This shouldn't be used on large complex datasets. It utilizes the relatively slow method of '?' randomized sorting. Use with caution. Todo: MySQL support, Support for larger datasets
**Use case:** Suppose you are working on maintenance screens on some data objects. On one particular page (a form) you want to have exits directly back to a calling page (as a cancel operation) or indirectly back to the calling page (after an data update operation). However, the form and its object are not directly related to the target page (perhaps a one-to-many relationship) so you cannot figure the calling page from object data - but the target object IS referenced in the url. ** How To:** To make this work, we need to pick out a variable from the URL of the current page and use it to generate the URL of the target page. 1. [urls.py] Models *Banker* and *Iaccount* are related as One-to-Many so if we are creating an *Iaccount* we cannot usually determine the *Banker* object to return to. In this example, URL1 contains the variable `iid` - the primary key to the Banker object; this will render a create form. We want to be able to reference URL2 from this form. 2. [views.py: get_initial] We can access the variable we want with `self.kwargs['iid']` and use it to set the initial value of the `ident` fields which links back to the *Banker* object 3. [views.py: get_success_url] In the same way we can pass the value into the form's *success_url* to point at URL2 4. [template] In the template, we can also access the variable now as `form.ident.value` so we can construct a *Go Back* link to URL2 Thanks to Thomas Orozco for leading the way.
Simplified version of the snippet that renders model to PDF [http://djangosnippets.org/snippets/2540/](http://djangosnippets.org/snippets/2540/) This PDF view mixin for Django Class Based Views. See working project example: https://github.com/elena/django-pdfmixin-example --- This is based on the case scenario where you have a model which has a `DetailView`. You then construct a bespoke PDF for the same model that is unrelated in any way to the `DetailView`. The PDF needs to be returned as a `HTTPResponse` object. The model object is provided.
There is a lot of debate on whether there is a real future for the Django CBVs (class based views). Personally, I find them tedious, and just wanted a way to keep my views clean. So, here is a really minimalistic way of having class based views, without the fuss. This is a fork from: http://stackoverflow.com/questions/742/class-views-in-django http://djangosnippets.org/snippets/2041/
This is a simplest approach possible. `as_view()` is replaced, so that it applies the given decorator before returning. In this approach, decorators are always put on top - that means it's not possible to have functions called in this order: B.dispatch, login_required, A.dispatch NOTE: By default this modifies the given class, so be careful when doing this: TemplateView = view_decorator(login_required)(TemplateView) Because it will modify the TemplateView class. Instead create a fresh class first and apply the decorator there. A shortcut for this is specifying the ``subclass`` argument. But this is also dangerous. Consider: @view_decorator(login_required, subclass=True) class MyView(View): def get_context_data(self): data = super(MyView, self).get_context_data() data["foo"] = "bar" return data This looks like a normal Python code, but there is a hidden infinite recursion, because of how `super()` works in Python 2.x; By the time `get_context_data()` is invoked, MyView refers to a subclass created in the decorator. super() looks at the next class in the MRO of MyView, which is the original MyView class we created, so it contains the `get_context_data()` method. Which is exactly the method that was just called. BOOM!