Decorator to make a view only accept requests from AJAX calls. Usage:: @require_xhr() def my_view(request): # Returns data # ... by [skam](http://skam.webfactional.com/)
Date-based generic views do not provide pagination by default but Django is very extensible. It provides a Paginator that takes care of pagination. Since date based views usually order by descending order ie from latest entry to the oldest, I used a queryset to order the items (on a field called 'date_pub') and then pass this queryset to the paginator which takes care of the pagination.
Slightly shonky implementation of a custom URL shortening view, as [described on my blog](http://simonwillison.net/2009/Apr/11/revcanonical/). Depends on [baseconv.py](http://www.djangosnippets.org/snippets/1431/)
Here's an example of writing generic views in an object-oriented style, which allows for very fine-grained customization via subclassing. The snippet includes generic create and update views which are backwards compatible with Django's versions. To use one of these generic views, it should be wrapped in a function that creates a new instance of the view object and calls it: def create_object(request, *args, **kwargs): return CreateObjectView()(request, *args, **kwargs) If an instance of one of these views is placed directly in the URLconf without such a wrapper, it will not be thread-safe.
One thing I wanted for a while was the ability to basically apply something like @login_required to a bunch of urlpatterns in one go, instead of having to decorate each and every view manually. In this example, the latter two views will always raise a 404.
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
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
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+.
Take the legwork out of processing forms. Most people have a very specific structure to how they process forms in views. If the request method is "GET", then some HTML (with the blank form) is rendered. If the method is "POST", then the form is validated. If the form is invalid, some other HTML is displayed. If valid, the data is submitted and processed in some way. In order to do this all in a much nicer way, simply subclass `FormHandler`, define three methods (`valid`, `invalid` and `unbound`), point to the form, and use the subclass as your view in the URLconf.
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.
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.
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.
Yet another implementation of class based RESTful dispatch. This particular implementation features: * You do not have to call __init__ from the derived classes. * Avoids __metaclass__ which (in our environment) led to unexpected method override behavior. * Method names match the google webapp API. * One new instance per request to reduce errors in multi-threaded code. Snippets of inspiration: * [436](http://www.djangosnippets.org/snippets/436/) * [437](http://www.djangosnippets.org/snippets/437/) * [1071](http://www.djangosnippets.org/snippets/1071/) * [1072](http://www.djangosnippets.org/snippets/1072/) * [1226](http://www.djangosnippets.org/snippets/1226/)
This example shows, how to use database views with django models. NewestArticle models contains 100 newest Articles. Remember, that NewestArticle model is read-only. Tested with mysql.