I had a difficult time understanding how to delete an item from a table within a template, using a modelform. I couldn't find a good example, so I wanted to post the code that ultimately worked.
I wanted to be able to share common code among a subset of views without copy-and-pasting the code or the same function into each view, so I decided to wrap a class around the views so that the common code (i.e. loading a model that each of the views would affect) can go in the __init__ of that class. I created the controller_view function above to allow the urls to access those class methods. It would be called something like this: url(r'^someview$', controller_view(SomeController, 'someview'), name='someview'), Where the SomeController inherits (or is structured like) the Controller class above and implements __init__ and someview as methods. I'm new to Django so it's entirely possible I've missed something that already does this or that makes this unnecessary. If so, let me know so that I can figure out how to do this right, otherwise, hopefully this is helpful to someone else out there.
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.
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 in my opinion a better way to have flat pages in a project. In the example with the url patterns settings: / will render -> /pages/welcome.html /contact will render -> /pages/contact.html /products/ will render -> /pages/products/index.html /products/pricing will render -> /pages/products/pricing.html
Register django views
Use this decorator in your views to cache HttpResponse per user, so each user has his own cache, instead of a shared one as `from django.views.decorators.cache.cache_page` does. Add this to use: from somewhere import cache_per_user @cache_per_user(ttl=3600, cache_post=False) def my_view(request): return HttpResponse("LOL %s"%(request.user)) All documentation inside the decorator are in brazilian portuguese, feel free to translate to english
Class that takes a normal none derived class and converts it into a view. The methods return simple datastructures which makes it easier to test.
If your URL pattern looks like: `urlpatterns = patterns('django.views.generic.create_update', url(r'^obj/(?P<obj_id>\d+)/new_thing$', create_object, {'form_class': ThingForm, 'template_name': 'thing/new_thing.html', extra_context: {:this":"that"}), )` You will receive an error, because the create_update view doesn't have a parameter called "obj_id". Supposing you want that variable in the URL, and furthermore let's say you wanted to do something with it in the template. With this function, you can wrap the view, and add the parameter capture_to_context, which maps URL variables to template variables: `urlpatterns = patterns('django.views.generic.create_update', url(r'^obj/(?P<obj_id>\d+)/new_thing$', view_url_vars_to_context(create_object), {'form_class': ThingForm, 'template_name': 'thing/new_thing.html', 'url_vars_to_context':{'obj_id':'objID'}, extra_context: {:this":"that"}}), )` Now objID will be a variable in your template, with the value given to obj_id. This is good for generic views, but there's no reason you couldn't use it for your own views if you really wanted, as long as you had an "extra_context" parameter.
Simplify views declararation. (Upd: add assertion)
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.
I work a little with [web.py framework](http://webpy.org/) and I like a lot the view definition. For each view you define a class and in that class you can define two method, GET and POST. If the http request is a GET request the GET method will be called and if http request is a POST request the POST method is called. Then you can define common stuff in another method that could be called inside each method, and you have a class for each view.
This Snippet allows a view to controle the printed forms on the templates, in a similar way to the fieldsets used by the django admin. How to Use: In the view in question, put: def some_view(request): ... fieldsets = ( (u'Title 1', {'hidden' : ('field_1', 'field_2',), 'fields' : ('field_3',)}), (u'Title 2', {'hidden' : ('field_5', 'field_6',), 'fields' : ('field_4',)}),) ) return render_to_response('some.html', {'fieldsets': fieldsets}) fieldsets = ( (None, {'hidden' : ('evento', 'colaborador',), 'fields' : ('acompanhantes',)}), ) Next, in the html just add: <form enctype="multipart/form-data" id="edit" method="post" ...> ... {% include "inc/form_snippet.html" %} ... <input type="submit" value="Submit"> </form>
Set session to never expire in settings, and when remember_me is found false in login POST, set it to browser session expiry. Works only in Django 1+.
simple routing views
35 snippets posted so far.