Render to email
Renders a view to an email. You need to set all of the required settings for email support.
- shortcut
- filter
- view
- render
Renders a view to an email. You need to set all of the required settings for email support.
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 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'
A simple view used to manage the page cache stored in the database (here Postgresql in the django_cache table, you also have to set correctly CACHE_TABLE_OID, by the OID of the cache table (you can get it in PgAdmin)
Subclass `Resource` to create a view that will dispatch based on the HTTP method of the request. class View(Request): def DELETE(self, request): ... def GET(self, request): ... def PUT(self, request): ... Other snippets provided 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/) The code is also available on [GitHub](http://github.com/jpwatts/django-restviews/).
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.
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.
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.
The @cache_holding decorator works in a per-function base, you can specify a list of models or just a model and the second argument is the time in seconds to be cached. You can modify the proxy class by a keyword argument so you can do cache to all kind of things, also if you want to use a prefix as key + the hash value you can specify the prefix keyword argument.
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 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!
Usage: @login_required def action_delete(request,object_id): return delete_view(request,object_id,ActionItem)
This is a simple helper to make custom permission decorators for Django views. Perhaps you have an edit_comment view which you want to make sure current user is the owner of: >def edit_comment(request, comment_id): >>if request.user == Comment(id=comment_id).user: >>>... do authorized things ... >>else: >>>... do unauthorized things ... >>... >>... In this view, you might do a quick check `if request.user == Comment(id=comment_id).user`, however you now need to duplicate this code all over the place whenever you want to check if a comment is owned by the current user. Instead, you can use the built in login_required decorator, and your own decorator to do the test: >@permission >def user_owns_comment(request, comment_id): >>return request.user == Comment(id=comment_id) > >@login_required >@user_owns_comment >def edit(request, comment_id): >> ... >> ... >> ... The "tester" function will post a message using the messages module built into Django, and redirect the user to the root. It allows access and executes the view if the tester function returns anything that evaluates to True. Your permission tester should either strictly specify the same arguments as the view, or take additional *args, and **kwargs to prevent syntax errors on extra arguments being passed along.
Defines a decorator ``API_magic'' which simplifies input-checking API views.
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.
55 snippets posted so far.