Django does not have a clean, built-in mechanism to separate GET and POST implementations. This simple decorator provides this behavior. Django does provide an alternate way using class-based views, but defining class for each of your view functions may be an overkill. You can name the get and post functions anything you wish, but you need to make sure they are returned in the same order (get first and then post).
Example usage:
@formview
def edit(request, id):
form = EditForm(id, request.POST or None)
def get():
return render(request, 'edit.html', {'form' : form})
def post():
if form.is_valid():
form.save(id)
return redirect('list')
return get, post
After using Zope3/Grok for a little, I wondered how hard it would be to implement views as classes in Django, in a similar vain to how it's done in Grok. I came up with something rather simple but effective. It may be more appropriate if you use a template engine other than Django Templates, which allows you to call functions with arguments, but it's still useful none-the-less to encapsulate functions in a class.
You could, for example, extend View to be JinjaView, just replacing render_template().
A nice extension, I imagine, would be to automatically figure out the template name as well as the path prefix for it (since you probably want it to be found under packagename/templatename.html).
Jinja2, while a great replacement for Django templates, is not a drop-in replacement for it. I wanted to use Photologue with my Jinja templates, but because Photologue uses Django generics, so I decided to see if I could use Jinja2 with generics, and then only modify the templates. It was a bit of work, but I seem to have done it. Django generics can take template_loader as an option, so if you have the same interface, things should just work.
The template must accept RequestContext as an argument to render(), so here we subclass jinja2.Template and when it receives Django's RequestContext object, it creates a flat dictionary from it, which jinja2 can work with.
This module is comes from the original staticview.py from django. But when you using it, it can looks for static files in your app's subdirectory. So that you can put static files which concerned with your app in a subdirectory of the app. I should say it method only suit for developing, so if you want to deploy your application to apache, you should copy static folder to the real media folder. And if you keep the same structure of the directory, then it'll be very easy. And you can write a little script to automatically do that. But for now, I didn't have written one yet :P
How to use it in urls.py
--------------------------
Here's an example:
(r'^site_media/(.*)$', 'utils.staticview.serve', {'document_root': settings.SITE_MEDIA, 'app_media_folder':'media'}),
It seems just like the original one in django. But there is a new parameter "app_media_folder", it's used for subdirectory name of app. So your django project folder structure maybe seem like this:
/yourproject
/apps
/appone
/media
/css
/img
/js
/media
/css
/img
/js