Sometimes it's useful to dispatch to a different view method based on request.method - e.g. when building RESTful APIs where GET, PUT and DELETE all use different code paths. RestView is an extremely simple class-based generic view which (although it's a stretch to even call it that) which provides a simple mechanism for dividing up view logic based on the HTTP method.
Peeping middleware, that replaces active user to another one for current http request. Admin permissions required to activate, so you can place this snippet even on the production server. Very useful for debugging purposes. Wish it to be part of Django. How to use: Put this middleware after all other middlewares in the list. Then just add ?as_user=username or &as_user=username to the url, where username is the name of user whose views you want to see.
This function emulates the file upload behaviour of django's admin, but can be used in any view. It takes a list of POST keys that represent uploaded files, and saves the files into a date-formatted directory in the same manner as a `FileField`'s `upload_to` argument.
This view snippet is a helper for implementing file download handlers. There is a standard to encode Unicode filenames properly, but many browsers have different protocols. The default encoding is assumed to be UTF-8.
The rationale behind this decorator is described in django-users google group. Usage: === urls.py === urlpatterns = patterns('', (r'^', include('apps.app1.views')), (r'^app2', include('apps.app2.views')), ) === apps/app1/views/__init__.py === @url(r'^index/$') def index(request): ... @url(r'^news/$') def news(request): ... urlpatterns += include_urlpatterns(r'^members', 'apps.app1.views.members') === apps/app1/views/members.py === @url(r'^profile/$) def profile(request): .... @url(r'^secure/$) def secure(request): ... @url(r'^path1/$', '^path2/$') # you can specify several patterns def multipath_view(request): ... def helper(): # easily distinguishable - no @url! ... Summarizing, the benefits are: * no more creating and supporting urlpattern maps (less files, less code, more DRY) * have the url associated with a view in-place * easily see if a function is a view * fully compatible with other chained decorators
Use this code to generate downloadable [vCard][] objects. See the [VObject docs][1] for more details on the API. [1]: http://vobject.skyhouseconsulting.com/ [vcard]: http://en.wikipedia.org/wiki/VCard
Inserts the output of a view, using fully qualified view name (and then some args), a or local Django URL. {% view view_or_url arg[ arg2] k=v [k2=v2...] %} This might be helpful if you are trying to do 'on-server' AJAX of page panels. Most browsers can call back to the server to get panels of content asynchonously, whilst others (such as mobiles that don't support AJAX very well) can have a template that embeds the output of the URL synchronously into the main page. Yay! Go the mobile web! Follow standard templatetag instructions for installing. **IMPORTANT**: the calling template must receive a context variable called 'request' containing the original HttpRequest. This means you should be OK with permissions and other session state. **ALSO NOTE**: that middleware is not invoked on this 'inner' view. Example usage... Using a view name (or something that evaluates to a view name): {% view "mymodule.views.inner" "value" %} {% view "mymodule.views.inner" keyword="value" %} {% view "mymodule.views.inner" arg_expr %} {% view "mymodule.views.inner" keyword=arg_expr %} {% view view_expr "value" %} {% view view_expr keyword="value" %} {% view view_expr arg_expr %} {% view view_expr keyword=arg_expr %} Using a URL (or something that evaluates to a URL): {% view "/inner" %} {% view url_expr %} (Note that every argument will be evaluated against context except for the names of any keyword arguments. If you're warped enough to need evaluated keyword names, then you're probably smart enough to add this yourself!)
This is a quick shortcut to redirect the user to a view. The main gain is avoiding having to type 'from django.core.urlresolvers import reverse' every time you want to do a redirect!
Instead of using a function for your views, this allows you to use a class. For your urls definition it works just as it normally does.
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/)
Decorator adding arbitrary HTTP headers to the response. This decorator adds HTTP headers specified in the argument (map), to the HTTPResponse returned by the function being decorated. Example: @headers({'Refresh': '10', 'X-Bender': 'Bite my shiny, metal ass!'}) def index(request): ....
Here are a couple of Django decorators for limiting access to a view based on the request's `HTTP_REFERER`. Both raise a Django `PermissionDenied` exception if the referer test fails (or a referer simply isn't provided). The first, `referer_matches_hostname`, takes a hostname (and port, if specified) and matches it against the referer's. If multiple arguments are supplied a match against any of the hostnames will be considered valid. The second, `referer_matches_re`, takes a regex pattern (like Django's urlpattern) and tests if it matches the referer. This is obviously more flexible than `referer_matches_hostname` providing the ability to match not just the hostname, but any part of the referer url. Finally there's an simple example decorator, `local_referer_only`, that limits a view to the current site by using Django's `django.contrib.sites` to look up the current hostname.
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).
This snippet suplies a resolve_to_name function that takes in a path and resolves it to a view name or view function name (given that the path is actually defined in your urlconf). Example: === urlconf ==== urlpatterns = patterns('' (r'/some/url', 'app.views.view'), (r'/some/other/url', 'app.views.other.view', {}, 'this_is_a_named_view'), ) === example usage in interpreter === >>> from some.where import resolve_to_name >>> print resolve_to_name('/some/url') 'app.views.view' >>> print resolve_to_name('/some/other/url') 'this_is_a_named_view'
Use this decorator on a function that returns a dict to get a JSON view, with error handling. Features: * response always includes a 'result' attribute ('ok' by default) * catches all errors and mails the admins * always returns JSON even on errors