If you require lots of forms in your project and do not want to be creating an extended template for each one I propose this solution. Classes in the html correspond to bootstrap, you can work without them if you do not use bootstrap.
This snippet is greatly inspired by [@jlorich](http://djangosnippets.org/users/jlorich/)'s useful [#2436](http://djangosnippets.org/snippets/2436/). The main difference is that I wanted to choose the names of my URL params instead of being forced into naming them "value1", "value2", etc. When reversing the URL you have to remember that the kwargs aren't friendly. By using the same names in the `filters` list, you don't have to change the way your otherwise write the URL pattern. Also it's clear throughout how you'll be filtering the QuerySet. The other change I made was "erroring early". This avoids running the QuerySet all over again inside `object_detail()` just to have it raise an exception we could have caught the first time.
Converts a passed decorator to one that can be applied to a class based view (ie. automatically decorates dispatch). This means no more overriding dispatch for every view / request method you want to apply decorators to. Works in Django 1.3 but I suspect it probably works in 1.2 as well.
This view acts as an extension to the object_detail generic view in django.views.generic.object_list. The standard generic view can only filter the queryset by object_id or slug; this view allows you to filter by any parameter you like, as well as multiple parameters. The usage is the same as the standard object_detail view except that you must also give the parameter 'filters', which should be an array of what you would like to filter the url values as, and instead of 'slug' or 'object_id' as the regex parameter in the URL, use 'value1', 'value2', etc. Example: If you have a list of companies, each with multiple branches, you may want a branch details page. A URL for this may look as follows: http://www.mysite.com/company/company-slug/branch-slug/. To implement this simply use the urlpattern example give,
These generic views extend default views so that they also do permission checking on per-object basis. * detail, update and delete - check access for user * create - create permissions for user on object * list - narrow object list with permissions Classes prefixed with Owned are example implementation where user has access to object if designed object attribute references him. Example: `create_article = OwnedCreateView.as_view(owner='creator', model=Article, form_class=ArticleForm, success_url='/articles/article/%(id)d')`
Simple wrappers around the new class-based generic views (introduced in Django 1.3) that also check permissions. **Example Usage** *(views.py)*: from mymodule import RestrictedListView, RestrictedUpdateView class MyListView(RestrictedListView): model = MyModel class MyUpdateView(RestrictedUpdateView): model = MyModel and so on for Create and Delete.
This should work as a `django.views.generic.list_detail` generic view but will produce PDF version of given template. This code is merged code from perenzo's [example](http://www.djangosnippets.org/snippets/659/) and code from `django.views.generic.list_detail` module. `pisa` package is required from (http://www.htmltopdf.org/download.html) with `html5lib` package and Reportlab Toolkit 2.1+ NOTE: this is code for Django 0.96. In Django 1.0 change in line 3: ObjectPaginator to Paginator
Based on [danjak's](http://www.djangosnippets.org/users/danjak/) [snippet](http://www.djangosnippets.org/snippets/99/) but updated to use ModelForms - so can easily handle generic CRUD operations. A replacement create_update.py for use with ModelForm create_object and update_project modified to handle newforms (including FileFields) with ModelForm - it also had delete_object as well for completeness. In addition, it has some extras: * extra_fields - this is a dict or callable that contains additional fields to be passed to the form, for example stuff that is in the session. * on_success - callback called if form is valid and object created/updated, if this is not set the default behaviour is to send a redirect * on_failure - callback called if form is invalid, the default is to redisplay the form. Note that once newforms are finally done these functions are likely to be redundant, as generic views will be updated to use the newforms API, so use with caution!
create_object and update_project modified to handle newforms (including FileFields). In addition, I have added some extras: 1. extra_fields - this is a dict or callable that contains additional fields to be passed to the form, for example stuff that is in the session. 2. on_success - callback called if form is valid and object created/updated, if this is not set the default behaviour is to send a redirect 3. on_failure - callback called if form is invalid, the default is to redisplay the form. Note that once newforms are finally done these functions are likely to be redundant, as generic views will be updated to use the newforms API, so use with caution.