Use this to display an object on a page AND be able to process a form on this page. This is just a copy of the [Django docs advice](https://docs.djangoproject.com/en/2.2/topics/class-based-views/mixins/#using-formmixin-with-detailview), but put as a reusable, standalone View.
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.
# Django AJAX Form View ### A simple example for an AJAX-powered view
Get the referer view of a request. **Example:** def some_view(request): ... referer_view = get_referer_view(request) return HttpResponseRedirect(referer_view, '/accounts/login/')
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 Mixin approach for applying permissions to CBV views suffers from 3 issues: 1. you need to read the code to see what permissions are being applied to a View 2. multiple bits of disparate code required to specify, e.g., a simple permission check 3. permissions set on a base class are overridden by permission set on sub-class, unless special care is taken Here's a nice trick, using only built-in django machinery, apply a decorator intended to decorate a django view function to a CBV view. https://docs.djangoproject.com/en/1.11/topics/class-based-views/intro/#decorating-the-class This approach works for any function decorators with arguments - simply wrap it in a function that takes the same arguments: def my_cbv_decorator(*args **kwargs): return method_decorator(a_view_function_decorator(*args, **kwargs), name='dispatch') Use your new CBV decorator to decorate View sub-classes: @my_cbv_decorator('some_parameter') class MyCBView(django.views.generic.TemplateView): pass # dispatch method for this view is now wrapped by a_view_function_decorator Note: you can also pass decorator parameter directly to method_decorator, but wrapping it up like this makes the code read nicer.
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.
Sample jQuery javascript to use this view: $(function(){ $("#id_username, #id_password, #id_password2, #id_email").blur(function(){ var url = "/ajax/validate-registration-form/?field=" + this.name; var field = this.name; $.ajax({ url: url, data: $("#registration_form").serialize(), type: "post", dataType: "json", success: function (response){ if(response.valid) { $("#"+field+"_errors").html("Sounds good"); } else { $("#"+field+"_errors").html(response.errors); } } }); }); }); For each field you will have to put a div/span with id like fieldname_errors where the error message will be shown.
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!)
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.
This snippet shows a way to preserve GET arguments with pagination. Many people make mistakes to omit the query arguments besides page arguments for the pagination, and making sure correct may sphagettize your code.
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
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
This is an example how to create a wrapping function that can read all incoming arguments, do something with them and then call the original function. This pattern works well with generic views. Note that wrapper function accepts arguments in both ways: as a list of unnamed arguments and as a list of keyword-value pairs. A real-world example: def published_object_list(request, *args, **kwargs): arg_names = object_list.func_code.co_varnames params = dict(zip(arg_names, args)) params.update(kwargs) params['queryset'] = params['queryset'].filter(is_published=True) if request.is_ajax(): params['template_name'] = "ajax/" + params['template_name'] return object_list(request, **params)
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): ....